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ABSTRACT 



tnesis presents an irr.piemer ration of process 
.nana^ement for a security Kernel based sf^cure arcnival 
storage system (?ASS). Tne implementioc is based cn a family 
of secure. distributed, rrulti-microproressor operating 
systems designed to provide multilevel internal security and 
contrcllea snaring of data an-ong autncrized users. Process 
scneduling is effected by one naif of a two level Traffic 
Controller tnat binds processes to virtualized processors. 
Inter-process communication mecnanisms for syn cnroni z ati on , 
mutual exclusion, and message passing among processes are 
provided by utilization of event''cunt and sequencer 
primitives. Tne implementation structure is based upon 
levels Of abstraction and is icop free to permit future 
expansion to more complex members of tne design family. 
Implementation was completed on tne ADVANCED .'ilCRC COy.PUTR'S 
sm 96/^116 AmZ80iJ2 16 rit yonoioard Computer. 
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I . INTRODUCTION 



This thesis addresses the impleri’entation of process 
management functions for the Secure Archival Storage System 
or SASS. This system is designed to provide multilevel 
secure access to information stored for a network of 
possibly dissimilar host computer systems and the controlled 
sharing of data amongst authorized users of the SASS. 
Effective process management is essential to insure 
efficient use and control of the system. 

Among the major accomplishments of the wort reported 
here are the inclusion of provisions for efficient process 
creation and management. These functions are provided 
through the establishment of a system Traffic Controller and 
the creation of a virtual interrupt structure. An effective 
mechanism for inter-process communication and 
synchronization is realized through an Event Manager that 
maies use of uniquely identified segments supported •►y 
eventcount and sequencer primitives. A hardware controlled 
two domain operational environment is created with the 

I 

necessary interfacing between domains provided by a software 
”gate” mechanism. Additional support is provided through 
considerable worir in the area of database initialization and 
a technique for limited dynamic memory allocation. 
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This implementation was completed on the commercial AMC 
Am96/4116 MonoBoard Computer with a standard Multibus 
interface . 



A. BACKGROUND 

The brief history of digital computers has been 
characterized by rapid advances in hardware technology and a 
continual increase in the number and variety of its 
applications. The advent of the microprocessor has enabled 
virtually every level of our society to mate use of computer 
resources. Today's "des4 top" microcomputers, costing less 
than a thousand dollars, have more computing power than the 
"giant" computers of the early I950's that cost hundreds of 
times that amount. 

These rapid advances in computer hardware technology 
have reversed the economics of the computer design 
environment. While hardware costs have decreased, the 
relative costs of the software required to effectively 
utilize this hardware nas steadily increased until it now 
dominates the overall cost of a computer system. This 
economic reversal requires that developed software be 
logical, easy to read, relatively maintenance free, and easy 
to debug. Unfortunately, microcomputer operating systems and 
applications software tend to be highly specialized, thus 
failing to reasonably exploit the potential of tne 
microprocessor. 
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As tne usaffe of computers has expanded, expeclaily in 
the area of sensitive information handling, the need for 
information security has received treater recognition. While 
ad-hoc attempts have been made to provide internal computer 
security on larger systems, the problem of information 
security on microprocessors has been largely ignored to 
date . 

In an attempt to address the above problems, O'Connell 
and Richardson [1] outlined a high level design for a 
microprocessor based secure operating system. The goal of 
this design was to provide information security, distributed 
processing, multiple protection domains, configuration 
Independence, multiprocessing, and multiprogramming. Since 
all computer applications do not require such a broad and 
general operating system, the design provided for a family 
of operating systems. This allows a member of the family to 
incorporate only the subset of family functions needed for 
its specific application, while providing for future 
expansion. The SASS is a member of this operating system 
family^ 

A brief history of prior wort done on the SASS is now 
provided. Parirs [Hj provided the design for the SASS 
Supervisor. Tne actual implementation of the Supervisor 
design has not been addressed to date. The initial design of 
the SASS Security Kernel was completed by Coleman [3J . The 
works of O'Connell and Richardson [Ij , Parirs [2J , and 
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Coleman [3] are available as a single publication from NTIS 
and DDC in a report prepared by Schell and Cox [21] . Further 



refinements of tne Kernel design and partial Kernel 
implementation has been accomplished in three additional 
thesis efforts. Moore and Gary [4j provided the detailed 
design and partial implementation of the Memory Manager 
module. Design refinements for the Inner Traffic Controller 
and Traffic Controller modules as well as implementation of 
the Inner Traffic Controller was provided by Reitz [5]. 
Wells [6j provided implementation of the Segment Manager and 
Non-Discretionary Security modules as well as partial 
Implementation of distributed Memory Manager functions. 
These design and implementation efforts provided the basis 
for the work described here. 



E. BASIC CONCEPTS /DEFINITIONS 

This section provides an overview of several concepts 
essential to the SASS design. Readers familiar with SASS or 
with secure operating system principles may wish to skip to 
the next section. 

1. Process 

The notion of a process has been viewed in many ways 
in computer science literature. Or^anicK [7] defines a 
process as a set of related procedures and data undergoing 
execution and manipulation, respectively, by one of possibly 
several processors of a computer. Madnick and Donovan [Bj 
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view a process as the locus of points of a processor 
executing a collection of programs. Reed [9j describes a 
process as the sequence of actions taJten by some processor. 
In other words, it is tne past, present, and future 
"history” of the states of the processor. In the SASS 
design, a process is viewed as a logical entity entirely 
characterized by an address space and an execution point. A 
process' address space consists of the set of all memory 
locations accessible by the process during its execution. 
This may be viewed as a set of procedures and data related 
to the process. The execution point is defined by the state 
of the processor at any ^iven instant of process execution. 

As a logical entity, a process may have logical 
attributes associated with it, such as a security access 
class, a unique identifier, and an execution state. This 
notion of logical attributes should not be confused with the 
more typical notion of physical attributes, such as location 



in memory, page s 


ize, etc. In 


SASS , a 


process 


is given 


a 


security access 


class, at 


the time 


of i ts 


creation , 


to 


specify what au 


thorizatlon 


it possesses in 


terms 


of 


information acces 


s (to be discussed in 


the next 


secti on) . 


It 



is also given a unique identifier that provides for its 
Identification by the system and is utilized for interaction 
atroDff processes. A process may exist in one of three 
execution states: 1) running, 2) ready, and 3) bloclced. In 
order to execute, a process must be mapped onto (bound to) a 
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pnysical processor in tne system. Sucn a process is said to 
tte in the "running" state. A process that is not mapped onto 
a pnysical processor, but is otherwise ready to execute, is 
In the "ready" state. A process in tne "’blocked" state is 
waiting for some event to occur in tne system and cannot 
continue execution until the event occurs. At that time, the 
process is placed into tne ready state. 

2. Information Security 

There is an ever increasing demand for computer 
systems that can provide controlled access to the data it 
stores. In this thesis, "information security" is defined as 
tne process of controlling access to information based upon 
proper authorization. The critical need for information 
security should be clear. Banks and other commercial 
enterprises risk the theft or loss of funds. Insurance and 
credit companies are bound by law to protect the private or 
otherwise personal information they maintain on their 
customers. Universities and scientific institutions must 
prevent the unauthorized use of their often over-burdened 
systems. The Department of Defense and other government 
agencies must face the very real possibility that classified 
information is beine compromised or that weapon systems are 
being tampered with. In fact, security related problems can 
be found at virtually every level of computer usa,se. 

In tne past, attempts nave been made to identify tne 
security weakness of computer systems by trial and error and 
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then fix them. However, Schell [li?] has shown that security 
cannot he "added on" to an existing system with any degree 
of confidence that the resulting security system is 
impregnable. Security must he explicitly designed into a 
system from first principles. The icey to achieving provable 
information security is realized in the concept of the 
"security kernel." Schell [llj provides a detailed 
discussion of the use of this concept in the methodical 
design of system security. 

The security of computer systems processing 
sensitive Information can be achieved by two means: external 
security controls and Internal security controls. In the 
first case, security is achieved by encapsulating the 
computer and all its trusted users within a single security 
perimeter established by physical means (e.g., armed guards, 
fences, etc.) This means of security is often undesirable 
due to its added cost of implementation, tne inherent risk 
of error-prone manual procedures, and the problem of 
trustworthy but error-prone users. Also, since all security 
controls are external to the computer system, the computer 
is incapable of securely handling data at differing security 
levels or users with differing degrees of authorization. 
This restriction greatly limits tne utility of modern 
computers. Internal security controls rely upon the computer 
system to internally distinguish between multiple levels of 
Information classification and user authorization. This is 
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clearly a irore desirable and flexible approacb to 
information security. Tnis does not mean, nowever, tnat 
external security is not needed. Tbe optimal approacn would 
be to utilize internal security controls to maintain 
information security and external security controls to 
provide pnysical protection of our system against sabotage, 

theft, or destruction. The primary concern of this thesis is 

✓ 

information security and will therefore center its 
discussion on the achievement of information security 
through implementation of the security kernel concept. 

One might argue that a "totally secure" computer 
system is one that allows no access to its classified or 
otherwise sensitive information. Sucn a system would not be 
of much value to its users. Therefore, when we say that a 
system provides information security, it is only secure with 
respect to some specific external security policy 
established by laws, directives, or regulations. There are 
two distinct aspects of security policy; non-discreti onary 
and discretionary. Each user (subject^ of the system is 
given a label denoting what classification or level of 
access the user is authorized. Likewise, all information or 
segments (objects) within the system are labelled with their 
classification or level of sensitivity. The 
non-dis creti onary security mechanism is responsible for 
comparing the authorization of a subject with the 
classification of an object and determining what access, if 
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any, should he granted. The DOD security classification 
system provides an example of the non-discretionary security 
policy and is the policy implemented in SASS. Tne 
discretionary security policy is a refinement of the 

non-discretionary policy. As sucn, it adds a higher degree 
of restriction by ailowinc a subject to specify or restrict 
who may have access to his files. It must be emphasized that 
the discretionary policy is contained within the 

non-discretionary policy and in no way undermines or 
substitutes for it. This prevents a subject from granting 
access that would violate the non-discretionary policy. An 
example of discretionary security is provided by the DOD 
"need to know" policy. In SASS, the discretionary policy is 
implemented within the supervisor [2j by means of an Access 
Control List (ACL). There is an ACL maintained for every 
file in tne system, wnich provides a list of all users 
authorized access to that file. Every attempt by a user to 
access a file is first cnecked against tne ACL and then 
checked against the non-discretionary security policy. The 
"least" or "most restrictive" access found in these checks 
is then granted to the user. 

The relationship between the labels associated with 
the subject's access class (sac) and the object's access 
class (oac) is defined by a lattice model of secure 



information flow [12J as follows ( 
relationship"): 



denotes no 
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sac 



oact 



1. sac = oaCf read and write access permitted 

2. sac > oac, read access permitted 

3. sac < oac, write access permitted 

4. sac I oac, no access permitted 

In order to understand how these access levels are 

determined, it is necessary to sain an awareness of and 

consideration for several basic security properties. 

The "Simple Security Property" deals with "read” 
access. It states that a subject may nave read access only 
to those object's whose classification is less than or equal 
to the classification of the subject. This prevents a 
subject from reading any object possessing a classification 
higher than his own. 

The "Confinement Property” (also known as 

"^-property” ) governs "write” access. It states tnat a user 
may be granted write access only to those objects whose 
classification is treater than or equal to the 

classification of the subject. This prevents a user from 
writing information of a higher classification (e.e.. 
Secret) into a file of a lower classification (e.g.. 
Unclassified). It is noted that while this property allows a 
user to write into a file possessing a classification higher 
than his own, it does not allow him access to any of the 
data in that file. The SASS design does not allow a user to 
"write u^” to higher classified files. Therefore, in SASS, 
"sac < oac” denotes "no access permitted.” 
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The "Compatibility Property deals with the creation 
of objects in a hierarchical structure. In SASS, objects 
(segments) are hierarcnicaily organized in a tree structure. 
This structure consists of nodes witn a root node from which 
the tree eminates. The Compatibility Property states that 
the classification of objects must be non-decreasing as we 
move down the hierarchical structure. This prevents a parent 
node from creatine a child node of a lower classification. 

Several prerequisites must be met in order to insure 
that the security feernel desien provides a secure 
environment. Firstly, every attempt to access data must 
invoke the Kernel. In addition, the Kernel must be Isolated 
and tamperproof. Finally, the Kernel design must be 
verifiable. This implies that the mathematical model, upon 
which the Kernel is based, must be proved secure and that 
the Kernel is shown is to correctly implement this model. 

3. Segmentation 

Segmentation is a key element of a security Kernel 
based system. A segment can be defined as a logical grouping 
of information, such as a procedure, file or data area [8J . 
Thereforet we can redefine a process' address space as the 
collection of all segments addressable by that process. 
Segmentation is the technique applied to effect management 
of those segments within an address space. In a segmented 
environment, all references within an address space require 
two components: 1) a segment specifier (number) and 2) the 
location (offset) within the segment. 
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A se^rment may nave several logical and pnysical 
attributes associated witn it. Tde logical attributes may 
include the segment's classification, size, or permissable 
access (read, write, or execute). These logical attributes 
allow a segment to nicely fit the definition of an object 
within the security Icernel concept, and thus provide a means 
for the enforcement of information security. A segment's 
physical attributes include the current location of the 
segment, whether or not the segment resides in main memory 
or secondary storage, and where the segment's attributes are 
maintained by a segment descriptor. The segment descriptors 
for each segment in a process' address space are contained 
within a Descriptor Segment (viz., the MMU Image in SASS) to 
facilitate the memory management of that address space. 

Segmentation supports information sharing by 
allowing a single segment to exist in the address spaces of 
multiple processes. This allows us to forego the maintenance 
of multiple copies of tne same segment and eliminates tne 
possibility of conflicting data. Controlled access to a 
segment is also enforced, since each process can nave 
different attributes (read/write) specified in its segment 
descriptor. In the implementation of SASS, any segment which 
is shared, but has "read only" access by every process 
sharing it, is placed in the processor local memory 
supporting each of these processes rather than in the global 
memory. This Implies the maintenance of multiple copies of 
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some snared segments. It is noted tnat tne problem of 
"conflicting data” is avoided since tnis only applies to 
read only segments. Tnis apparent waste of memory and nonuse 

of existing snaring facilities is justified dy a design 
decision to provide maximum reduction of bus contention 
among processors accessing glodal memory. This reduction in 
bus contention is considered to be of more importance tnan 
the saving of memory space provided by single copy sharing 
of read only segments. This decision is also well supported 
by the occurrence of decreasing memory costSt which we have 
experienced in terms of high speed bus costs. 

4. Protection Domains 

The requirement for isolating the Kernel from the 
remainder of the system is achieved by dividing the address 
space of each process into a set of hierarchical domains or 
protection rings [13J . O'Connell and Richardson [Ij defined 
three domains in the family of secure operating systems: the 
user, the supervisor, and the Kernel. Only two domains are 
actually necessary in the SASS design since it does not 
provide extended user applications. The Kernel resides in 
the inner or most privileged domain and has access to ail 
segments in an address space. System wide data bases are 
also maintained within the Kernel domain to insure their 
accessibility is only through the Kernel. Tne Supervisor 
exists in the outer or least privileged domain where its 
access to data or segments within an address space is 
restri cted . 
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While protection domains may Pe created through 
either hardware or software mechanisms, a hardware 
implementation provides much greater efficiency. Current 
microprocessor technology only provides for the 
implementation of two domains. This two domain restriction 
does not support O'Connell and Richardson's complete family 
design, hut it is sufficient to allow hardware 
implementation of the ring structure required by the SASS 
subset. 



5. AlLS.mfi.tl Qfl 

Dijfcstra [14] has shown that tne notion of 
abstraction can be used to reduce the complexity of a 
problem by applying a general solution to a number of 
specific cases. A structure of increasing levels of 
abstraction provides a powerful tool for tne design of 
complex systems and generally leads to a better design with 
greater clarity and fewer errors. 

Eactt level of abstraction creates n virtual 

hierarchical machine [8] which provides a set of "extended 
instructions” to the system. A virtual machine cannot maice 
calls to another virtual machine at a higher level of 
abstraction and in fact is unaware of its existence. This 
implies that a level of abstraction is independent of any 
higher levels. This independence provides for a loop-free 
design. Additionally, a higher level may only ma^e use of 
the resources of a lower level by applying the extended 
instruction set of the lower level virtual machine. 
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Therefore, once a level of aostractlon is created, any 
nigner level is only interested in the extended instruction 
set it provides and is not concerned with the details of its 
implementation. In SASS, once a level of abstraction is 
created for the physical resources of the system, these 
resources become "virtualized" making the higher levels of 
the design independent of the physical configuration of the 
system. 



C. THESIS STRUCTURE 

This thesis describes the implementation of the process 
management functions for the SASS. The design base for this 
implementation evolved from the secure family of operating 
systems designed by O'Connell and Richardson [Ij . The 
programming language utilized in this implementation was 
PLZ/ASM assembly code [20J . 

Chapter I provided an introduction to the Secure 
Archival Storage System and a discussion of the basic 
concepts which underlie a secure operating system 

envi ronment . 

Chapter II will provide a discussion of tne SASS design. 
An overview of the entire SASS system is presented along 
with more detailed description of the modules comprising 
SASS and their associated databases. 

Chapter III discusses the issues bearing on this 
Implementation and the refinements made to previous SASS 
related worK. A discussion concerning the initialization of 
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tne databases utilized by tne current SASS demonstration is 
also presented. 

Chapter IV presents the implementation of process 
management (viz., tne Traffic Controller, Event Manager, 
Distributed Memory Manager, and Gate Keeper stub modules). A 
description of design and implementation criteria, and 
decisions made during implementation are also discussed in 
this chapter. 

Chapter V provides the conclusions reached, the status 
of the research, and recommendations relative to the 
continuation and extension of this worir. 

The appendices include the PLZ/ASM code for tne modules 
implemented and refined. The complete program listings for 
the Secure Archival Storage System may be obtained from a 
report prepared by Schell and Cox L22] . 
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II. SECURE ARCHIVAL STORAGE SYSTEM DESIGN 



This chapter provides an overview of the SASS in its 
current design state. The intent of this summary is 
threefold. First, it is intended to provide an overall 
understanding of the SASS itself. Secondly, it will provide 
an interrelationship between the work done in this thesis 
and previous wortc performed on SASS. Lastly, it provides a 
current base upon which further SASS development can occur. 



A. BASIC SASS OVERVIEW 



The purpose of the Secure Archi 
provide a secure ’’data warehouse" or 
can be accessed and shared by 
computer systems possessing 
classifications. The primary goals o 
provide information security and co 
among system users. 

Figure 1 provides an example of 
The system is used exclusively 
storage system and does not provide 
to its users. Thus the users of the 
store, retrieve, or modify files w 
computers are hardwired to the syste 
the Z8001 with each connection 



val Storage System is to 
information pool which 
a variable set of host 
differing security 
f the SASS design are to 
ntrolled sharing of data 



a possible SASS usage, 
for managing an archival 
any programming services 
SASS may only create, 
Ithin the SASS. The host 
m via the I/O ports of 
having a fixed security 
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classification. Eacfi host must have a separate connection 
for each security level it wishes to worfi: on (It is 
important to note that Figure 1 only represents the logical 
interfacing of tne system. Specifically, the actual 
connection with the host system must he interfaced with the 

Kernel as the I/O instructions for tne port are privileged). 

/ 

In our example. Host #1 can create and modify only Top 
Secret files, hut it can read files which are Top Secret, 
Secret, Confidential, or Unclassified. Llirewise, Host #2 can 
create or modify secret files, using its secret connection 
or confidential files, using its confidential connection. 
Host #2 cannot create or modify Top Secret or Unclassified 
files. 

In order to provide information security and controlled 
sharing of files, the SASS operates in two domains: (l) the 
Supervisor domain and (2) tne Kernel domain. The SASS 
achieves this desired environment through a distributed 
operating, system design which consists of two primary 
modules: the Supervisor and the Security Kernel. Each host 
system connected to the SASS nas associated with it two 
processes within the SASS which perform the data transfer 
and file management on benalf of that host. Tne host 
computer communicates directly with its own I/O process and 
File Manager process within tne SASS. 

We can use our notion of abstraction to present a system 
overview of the SASS. The SASS consists of four primary 
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levels of 
Level 
Level 

Level 1-Ttie Security Xernel 
Level 0“The SASS Hardware 
A pictorial representation of 
is presented in Figure 2. This 
a dual nost system for clarity 
that the Gate Keeper module is 
boundary between levels one 
described separately. 

Level 3» the host computer 
been addressed. It should 
maJces no assumptions about 
Therefore each host may be 
(i.e.~ micro, mini, or maxi-co 
the necessary physical secu 
their respective data linAs wi 



tern overview 
limited to 
ctions. Note 
the logical 
will be 

systems, of SASS has already 
be noted that the SASS design 
the host computer systems, 
of a different type or size 
mputer system). Furthermore,* 
rity of tne host systems and 
th the SASS is assumed. 



abstraction : 

3-The Host Computer Systems 
2-The Supervisor 

this abstract sys 
representation is 
and space restri 
in actuality 
and two and as such 



B. SUPERVISOR 

Level 2 of the SASS system is composed of the Supervisor 
domain. As already stated, the SASS consists of two domains. 
The actual implementation of these domains was e-reatly 
simplified since the ZSOOl microprocessor provides two modes 
of execution. The system mode, with which the Kernel was 
implemented, provides access to all machine instructions and 
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Figure 2. System Overview (Dual Host) 



which 



all segments within the system. The normal mode, with 
the Supervisor was implemented, only provides access to a 
limited subset of machine instructions and segments within 
the system. Therefore, tne Supervisor operates in an outer 
or less privileged domain than the Kernel. 

The purpose of tne Supervisor is to manage tne data link 
between the host computer systems and the SASS by means of 
Input/Output control, and to create and manage tne file 
hierarchy of each host within the SASS. These functions are 
accomplished via an Input/Output (I/O) process and a File 
Manager (FM) process within the Supervisor. A separate FM 
and I/O process are created and dedicated to each host at 
the time of system initialization. 

1 . File Manager Process 

The FM process directs the interaction between the 
host computer systems and the SASS. It interprets all 
commands received from the Host computer and performs the 
necessary action upon them through appropriate calls to the 
Kernel. The primary functions of the FM process are tne 
management of the Host's virtual file system and the 
enforcement of the discretionary security policy. 

The virtual file system of the Host is viewed as a 
hierarchy of files which are implemented in a tree 
structure. The five basic actions which may be initiated 
upon a file at this level are: 1) to create a file, 2) to 
delete a file, 3) to read a file, 4:) to store a file, and 5) 
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to modify a file. The I'M process utilizes a IM Known Segment 
Table (FM_KST) as tne primary database to aid in tnis 
management . 

Tde FM process maintains an Access Control List 
(ACL) through which it enforces tne discretionary security 
in SASS. The FM process initializes an ACL for every file in 
its Host's file system. The ACL is merely a list of all 
users that are authorized to access mat file. Tne ACL is 
checfeed upon every attempt to access a file to determine its 
authorization. The user (nost computer) directs tne FM 
process as to what entries or deletions should be made in 
tne ACL, and as such, specifies wno ne wisnes to nave access 
to his file. As noted earlier, discretionary security is a 
refinement to the Non-Discretionary Security Policy and 
therefore can only be utilized to add further access 
restrictions to those provided by the Non-Discretionary 
Security.' This prevents a user from granting access to a 
file to someone who otherwise would not be authorized 
access . 

2. Input/Output Process 

The I/O process is responsible for managing the 
input and output of all data between tne nost computer 
systems and the SASS. The I/O process is subservient to the 
FM process and receives all of its commands from it. Data is 
transferred between the SASS and Host Computer systems in 
fixed size "pacicets". These paclcets are brolcen up into three 
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basic types: 1) a synchronization packet, 2) a comnand 
packet, and 3) a data packet. In order to insure reliable 
transmission and receipt of packets between the Eost 
computer and the SASS, there must exist a protocol between 
them. Parks [2] provides a more detailed description of 
these packets, and a possible multi-packet protocol. 

C. GATE KEEPER 

The primary objective of the gate keeper is to isolate 
the Kernel and make it tamperproof. This goal is 
accomplished by reason of a software ring crossing mecnanism 
provided by the ^ate keeper. In terms of SASS, this notion 
of ’’ring-crossing" is merely the transition from tne 
Supervisor domain to the Kernel domain. As noted earlier, 
the gate keeper establishes the logical boundary between the 
Supervisor and the Kernel, and as a matter of course, it 
provides a single software entry point (enforcea by 
hardware) into the Kernel. Therefore, any call to the Kernel 
must first pass through the gate keeper. 

The ffate keeper acts as a trap handler. Once it is 
invoked by a user (Supervisor) process, the hardware preempt 
interrupts are masked, and the user process' registers and 
stack pointer are saved (within the kernel domain). It then 
takes the arsuirent list provided by the caller and validates 
these passed parameters to insure tneir correctness. To aid 
in the validation of these parameters, the ^ate keeper 
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utilizes tne Parameter Table as a database. Tne Parameter 
table contains all of tne permitted functions provided by 
the Kernel. These relate directly to the extended 
instruction set (viz.. Supervisor calls) provided by the 
Kernel (these extended instructions will be described in the 
next section). If an invalid call is encountered by the gate 
iteeper, an error code is returned, and the Kernel is not 
invoiced. If a valid call is encountered by the gate Keeper, 
the arguments and control are passed to the appropriate 
Kernel module. 

Once the Kernel has completed its action on tne user 
request, it passes the necessary parameters and control bacjc 
to the gate Keeper. At this point, the gate Keeper 
determines if any software virtual preempt interrupts have 
occurred. If they have, then the virtual preempt handler is 
invoKed vice the Kernel being exited (virtual interrupt 
structure is discussed in chapter III). Correspondingly, if 
a software virtual preempt has not occurred, then the return 
arguments are passed to the user process. The user process' 
registers and stacK pointer (viz., its execution point) are 
restored and control returned to the Supervisor domain. A 
detailed description of the Gate Keeper interface and 
implementation is provided in chapter IV. 
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D. DISTRIBUTED KERNEL 

Level 1 of our abstract view of SASS consists of two 
components: the distributed Kernel and the non-di stri buted 
Kernel. These two elements comprise the Security Kernel of 
the SASS. The Security Kernel has two primary objectives: 1) 
the management of the system's hardware resources, and 2) 
the enforcement of the non-discretionary security policy. It 
executes in the most privileged domain (viz., the system 
mode of the Z8001) and has access to all machine 
instructions. The following section will provide a brief 
description of the distributed Kernel, its components, and 
the extended instruction set it provides. A discussion of 
the non-distributed Kernel will be giver in the next 
section. 

The distributed Kernel consists of those Kernel modules 
whose segments are contained (distributed) in the address 
space of every user (Supervisor) process. Thus, in effect, 
the distributed Kernel is shared by all user processes in 
the SASS. The distributed Kernel is composed of the Segment 
Manager, the Event Manager, the Non-Discretionary Security 
Module, the Traffic Controller, the Inner Traffic 
Controller, and the Distributed Memory Manager Module. The 
Segment Manager and the Event Manager are the only "user 
visible" modules in the distributed Kernel. In other words, 
the set of extended instructions available to user processes 
invofce either the Segment Manager or the Event Manager. 
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1 . Segment Manager 

The objective of the Segment Manager is the 
management of a process' segmented virtual storage. The 
Segment Manager is invoiced by calls from the Supervisor 
domain via the gate iceeper. Calls to tne Segment Manager are 
made by means of six extended instructions provided by the 
segment manager. These extended instructions (viz., entry 
points) are: l) CRBAT]!)_SEGMENT , 2) DELETE_SEGMENT , 3) 
MAKB_KNOWN, 4) TERMINATE, 5) SM_SWAP_IN, and 6) SM_SWAF_OUT. 
The extended instructions CREATE_SEGMENT and DELETE_SEGMENT 
add and remove segments from the SASS. MAKE_KNOWN and 
TERMINATE add and remove segments from the address space of 
a process. Finally, SM_SWAP_IN and SM_SWAP_OUT move segments 
from secondary storage to main storage and vice versa. 

The primary database utilized by the Segment Manager 
is the Known Segment Table (KST) . A representation of the 
structure of the KST is provided in figure 3. The KST is a 
process local database that contains an entry for every 
segment in the address space of that process. The KST is 
indexed by segment number with each record of the KST 
containing descriptive information for a particular segment. 
The KST provides a mapping mechanism by which the segment 
number of a particular segment can be converted into a 
unique handle for use by the Memory Manager. The Memory 
Manager will be discussed in the next section. 
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2. Event t*^anager 



The purpose of the Event Manager is the management 
Of event data which is associated with interprocess 



communi cations 


wi thin 


tne SASS. 
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even t 


data 
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means 
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(a synchronization 


primitive discussed by 


Reed [15J ) . 


Tne 


Event 


Manager 


is 



invoked, via the Gate Keeper, by user processes residing in 
the Supervisor domain. There are two eventcounts associated 
with every segment existing in the Supervisor domain. These 
eventcounts (viz., Instance l and Instance 2) are maintained 
in a database residing in the Memory Manager. The Event 
Manager provides its management functions through its 
extended instruction set READ, TICKET, ADVANCE, and AWAIT, 
and in conjunction with the extended instructions TC_ADVANCE 
and TC_AWAIT provided by the Traffic Controller (to be 
discussed next). These extended instructions are based on 
the mechanism of eventcounts and sequencers [15J . The Event 
Manager verifies the access permission of every interprocess 
communication request through the Non-Discretionary Security 
Module. The extended instruction READ provides tne current 
value of the eventcount requested by the caller. TICKET 
provides a complete time ordering of possibly concurrent 
events through the mechanism of sequencers. The Event 
Manager will be discussed in more detail in chapter IV. 

3. Non-Discretionary Security Module 

The purpose of the Non-Discretionary Security Module 
(NDS) is the enforcement of the non-discretionary security 
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policy of tne SASS. Wnile tne current implementation of SASS 
represents tne Department of Defense security policy, any 
security policy wnicn may be represented tnrougn a lattice 
structure Ll2] may also be implemented, Ttie NDS is invoiced 
via its extended instruction set: CLASS_E0 and CLASS_GE. Tne 
NDS is passed two classifications which it compares and then 
analyzes their relationship. CLASS_E0 will return a true 
value to the calling procedure only if the two 
classifications passed were equal. The CLASS_GE instruction 
will return true if a siven classification is analyzed to be 
either greater than or equal to another given 
classification. The NDS does not utilize a data base as it 
worts only with tne parameters it is passed. 

4. Traffic Controller 

The tast of processor scheduling is performed by the 
traffic controller. Saltzer [16J defines traffic controller 
as the processor multiplexing and control communication 
section of an operating system. The current SASS design 
utilizes Reed's [9J notion of a two level traffic 
controller, consisting of: 1) a Traffic Controller (TC) and 
2) an Inner Traffic Controller (ITC). 

The primary function of the Traffic Controller is 
the scheduling (binding) of user processes onto virtual 
processors. A virtual processor (VP) is an abstract data 
structure that simulates a physical processor through the 
preservation of an executing process' attributes (viz., tne 
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execution point and address space). Multiple VP's may exist 
for every pnysical processor in the system. Two VP's are 
permanently bound to Kernel processes (viz., Memory Manager 
and Idle) and as sucft are not in contention for process 
scheduling. These processes and tneir corresponding virtual 
processors are invisible to the TC. The remainine virtual 
processors are either idle or are temporarily bound to user 
processes as scheduled by the TC . The database utilized by 
the TC in process scheduling is the Active Process Table 
(APT). Figure 4 provides the structure of the APT. 

The APT is a system-wide Kernel database containing 
an entry for every user process in the system. Since the 
current SASS design does not provide for dynamic process 
creation/deletion, a user process is active for the life of 
the system. Therefore, tne size of the APT is fixed at the 
time of system veneration. The APT is logically composed of 
three parts: l) an APT header, 2) the main body of tne APT, 
and 3) a VP table. The APT header includes: 1) a LocJc to 
provide for a mutual exclusion mechanism, 2) a Running List 
indexed by VP ID to identify the current process running on 
each VP, 3) a Ready List, which points to the lintted list of 
processes which are ready for scheduling, and 4) a PlocAed 
List, Which points to the linked list of processes which are 
in the blocked state awaiting the occurrence of some event. 

A design decision was made to incorporate a single 
list of blocked processes instead of the more traditional 
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per eveiucount because of its 



notion of separate lists 
simplicity and its ease of implementation. Tdis decision 
does not appreciably affect system performance or efficiency 
as the "blociced" list will never be very long. The VP table 
is indexed by logical CPU number and specifies the number of 
VP's associated with the logical CPU and its first VP in the 
Running List. The logical CPU number, obtained during system 
initialization, provides a simple means of uniquely 
identifying each physical CPU in the system. The main body 
of the APT contains the user process data required for its 
efficient control and scheduling. NEXT_AP provides the 
linked list threading mechanism for process entries. The DBR 
entry is a handle identifying the process' Descriptor 
Segment which is employed in process switching and memory 
management. The ACCESS_CLASS entry provides every process 
with a security label that is utilized by the Event Manager 
and the Segment Manager in the enforcement of the 

Non-Discreti onary Security Policy. The PRIORITY and STATE 
entries are the primary data used by the Traffic Controller 
to effect process scheduling. AEEINITY identifies the 
logical CPU which is associated with the process. VP ID is 
utilized to identify the virtual processor that is currently 
bound to the process. Finally, the EVENTCOUNT entries are 
utilized by the TC to manage processes which are blocked and 
awaiting the occurrence of some event. HANDLE identifies the 
segment associated with the event, INSTANCE specifies the 
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evenit and COUNT deterr’ines which occurrence of ihe event is 
needed . 



The Traffic Controller determines the scheduling 
order hy process priority. Every process is assigned a 
priority at the time of its creation. Once scheduled, a 
process will run on its VP until it either bioclts itself or 
it is preempted by a higher priority process. To insure that 
the TC will always have a process available for scheduling, 
there logically exists an "idle” process for every VP 
visible to the TC. These "idle" processes exist at the 
lowest process priority and, consequently, are scheduled 
only if there exists no useful worK to be performed. 

The Traffic Controller is invoiced by the occurrence 
of a virtual preempt interrupt or through its extended 
instruction set: ADVANCE, AWAIT, PHOCESS_CLASS , and 

GST_DBP._NUMBER . advance and AWAIT are used to implement the 
IPC mechanism envofced by the Supervisor. PR0CESS_C1ASS and 
GET_DBR_NDMBER are called by the Segment ^'anaffer to 
ascertain the security label and DBR handle, respectively, 
of a named process. A more detailed discussion of the TC is 
provided in chapters III and IV. 

5. Inner Traffic Controller 

The Inner Traffic Controller is the second part of 
our two-level traffic controller. Basically, the ITC 
performs two functions. It multiplexes virtual processors 
onto the actual physical processors, and it provides the 
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primitives for wnicn inter-VP communication witnin tne 
Kernel is implemented. A design cnolce was made to provide 
eacn pnysical processor in tne system vltn a small fixed set 
of virtual processors. Two of tnese VP's are permanently- 
bound to tne Kernel processes. Tne Memory Manager is tound 
to the nignest priority VP. Conversely, tne Idle Process is 
bound to tne lowest priority VP and. as a result, will only 
be scneduled if tnere exists no useful work for tne CPU to 
perform. Tne primary database utilized by tne ITC is tne 
Virtual Processor Table (VPT). Figure 5 illustrates tne VPT. 

Tne VPT is a system wide Kernel database containing 
entries for every CPU in tne system. Tne VPT is logically 
composed of four parts: l) a neader, 2) a VP data table, 3) 
a message table, and 4) an external VP list. The header 
includes a LOCK (spin lock) that provides a mutual exclusion 
mechanism for table access, a RUNNING LIST (indexed by 
logical CPU #) that identifies tne V? currently running on 
the corresponding pnysical CPU, a READ! LIST (indexed by 
logical CPU #) wnicn points to tne linked list of VP's wnicn 
are in tne "ready” state and awaiting scheduling on that 
CPU, and a FREE LIST wnicn points to tne linked list of 
unused entries in the message table. Tne VP data table 
contains tne descriptive data required by tne ITC to 
effectively manage the virtual processors. The DBR entry 
points witnin tne MMU Image to tne descriptor segment for 
the process currently running on tne VP. PRI (Priority), 
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STATE, IDLE_FLAG, and PREEMPT are tne prlnary data used by 
the ITC for VP scdeduling. PREEMPT indicates whether cr not 
a virtual preempt is pending for the VP. The IDLE_FLAG is 
set whenever the TC has bound an "idle" process to the VP. 
Normally, a VP with the IDLE_FLAG set will not be scheduled 
by the ITC as it has no useful worfc to perform. In fact, 
such a VP will only be scheduled if tne PREEMPT flag is set. 
This scheduling will allow the VP to be given (bound) to 
another process. PHYSICAL PROCESSOR contains an entry from 
the Processor Data Segment (PRDS) that identifies the 
physical processor that the VP is executing on. £iT_V?_ID is 
the identifier by which the VP is fcnown by the Traffic 
Controller. A design choice was made to nave tne EXT_VP_ID 
equate to an offset into the External VP List. The External 
VP List specifies tne actual VP ID (viz., VPT entry number) 
for each external VP identifier. This precluded tne 
necessity for run time calculation of offsets for the 
EXT_''^P_ID. NEXT READY VP provides the threading mechanism 
for the ’’Ready" linlced list, and MSG LIST points to the 
first entry in the Message Table containing a message for 
that VP. The Message Table provides storage for the messages 
generated in the course of Inter-Virtual Processor 
communications. MSG contains tne actual communication being 
passed, while SENDER identifies the VP which initiated the 
communication. NEXT_MSG provides a threading mechanism for 
multiple messages pending for a single VP. 
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The ITC is invoked by means of its extended 
instruction set: WAIT, SIGNAL, SWAP_7DBR, IDLE, SET_PREE(^PT , 
and RUNNING_VP. WAIT and SIGNAL are the primitives employed 
in implementing the Inter-VP communication. SWAP_VDBR, IDLE, 
SET_PREEMPT, and RUNNING_VP are all invoted by tne Traffic 
Controller. SWAP_VDBR provides the means by whicn a user 
process is temporarily bound to a virtual processor. IDLE 
binds the "idle” process to a VP (the implication of this 
instruction will be discussed later). SET_PREEf^PT provides 
the means of indicating that a virtual preempt interrupt is 
pending on a VP (specified by the TC ) by settinff the PREEMPT 
flag for that VP in the VPT. RUNNING_VP provides the TC with 
the external VP ID of the virtual processor currently 
running on the physical processor. 

6 . Distributed Memory Manager 

The Distributed Memory Manager provides an interface 
structure between the Segment Manager and the Memory Manager 
Process. This interfacing is necessitated by the fact that 
the Memory Manager Process does not reside in the 
Distributed Kernel and consequently is not included in the 
user process' address space. The primary functions performed 
in this module are tne establishment of Inter-VP 
Communication between the VP bound to its user process and 
the VP permanently bound to the Memory Manager Process, the 
manipulation of event data, and the dynamic allocation of 
available memory. The Distributed Memory Manager Module is 
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invoked ty tne Segment Manager tnrougn its extended 
instruction set: MM_CREATE_£NTR Y , MM_EELETE_ENTRY . 
MM_ACTIVATE, MM_DEACTI VATE , MM_SWAP_IN, and MM_SWAP_OUT. 
Tnese extended instructions are utilized on a one to one 
basis by tne extended instruction set of the Segment Manager 
(e.g., SM_SWAP_IN utilizes (calls) MM_SWAP_IN). Wells (6J 
provides a more detailed description of tnis portion of tne 
Distributed Memory Manager and tne extended instruction set 
associated with it. 

The Distributed Memory Manager is also invoked 
tnrougn its remaining extended instructions: 
MM_RSAD_EVBNTCOUNT, MM_TICKET, MM_ADVANCE, and MM_ALLOCATE. 
These Distributed Memory Manager functions will be discussed 
in detail in chapter IV. 

E. NON-DISTRIBUTEB EERNEL 

The Non-Distri buted Kernel is the second element 
residing in Level i of our abstract system view of tne SASS. 
The sole component of the Non-Dis tri bu ted Kernel is the 
Memory Manager Process. 

1 . Memory Manager Process 

Tne primary purpose of tne Memory Manager Process is 
the management of all memory resources within the SASS. 
These include tne local and global main memories, as well as 
the hard-disk based secondary storage. A dedicated Memory 
Manager Process exists for every CPU in tne system. Eacn CPU 
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possesses a local memory where process local segments and 
shared, non-wr iteable segments are stored. There Is also a 
global memory, to which every CPO has access, where the 
shared, writeable segments are stored. It is necessary to 

store these shared, writeable segments in the global memory 

to ensure that a current copy exists for every access. 

The Memory Manager Process is tasJced by other 

processes within the Kernel domain (via Signal and Walt) to 
perform memory management functions. These basic functions 
include the allocation/deallocation of local and global 
memory and of secondary storage, and the transfer of 

segments between tne local and global memory and between 
secondary storage and the main memories. The extended 
Instruction set provided by tne Memory Manager Process 
includes: CHEATE ENTRY, DELETE ENTRY, ACTIVATE, DEACTIVATE, 



SWAP_IN, and SWAP_OUT. These instructions correspond one to 
one with those of the Distributed Memory Manager Module. The 
system wide data bases utilized by all Memory Manager 
Processes are the Global Active Segment Table (G_AST), the 
Alias Table, the Dlslr Bit Map, and the Global Memory Bit 
Map. The processor local databases used by each Memory 
Manager Process are tne Local Active Segment Table (L_AST), 
and the Local Memory Bit Map. Gary and Moore [4j provide a 
detailed description of tne Memory Manager, its extended 
instruction set, and its databases. 
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A summary of tiie extenctea instruction set createa ty 
the components of the Security Kernel is provided by Fii^ure 
6. One mient question tne prudence of omitting 
FHTS_PPEEMPT_HANDLER and VIRT_PHEEMPT_HANDiSH (viz., the 
handier routines for physical and virtual interrupts^ from 
the extended instruction set as both of these interrupts may 
he raised (viz., initiated) from within tne Kernel. A 
decision was made to not classify these handlers as 
’’extended instructions” since they are only executed as the 
result of a physical or virtual interrupt and as such cannot 
be directly invoiced (viz., ’’called”) by any module in the 
system. A summary of tne databases utilized by Kernel 
modules is presented in Figure 7. 

F. SYSTEM HARDWARE 

Level 0 of the SASS consists of the system hardware. 
This hardware includes: 1) tne CPU, 2) tne local memory, 3) 
the global memory, 4) the secondary storage (viz. hard 
disfc), and 5) tne I/O ports connecting tne Host computer 
systems to the SASS. Since the SASS design allows for a 
multiprocessor environment, there may exist multiple CPU's 
and local memories. The target machine selected for the 
initial implementation of tne system is tne Zilog Z8001 
microprocessor ll7] . The Z8001 is a general purpose lb-bit, 
register oriented machine that has sixteen 16-bit general 
purpose registers. It can directly address 8M bytes of 
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Figure 6. Extended Instruction Set 
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Figure 7. Kernel Databases 
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memory, eiiensibie to 48M oyies . Tne Zb0fe)l arcnl tecture 
supports memory segmentation and two-domain operations. The 
memory segmentation capability is provided externally by the 
Zilog Z8010 Memory Management Unit (MMU). The Z8C10 MMU [ISJ 
provides management of tne Z8001 addressable memory, dynamic 
segment relocation, and memory protection. Memory segments 
are variable in size from 256 bytes to 64K bytes and are 
identified by a set of 54 Segment Descriptor Registers, 
which supply the information needed to map logical memory 
addresses to physcal memory addresses. Sach of the 64 
Descriptor Registers contains a 16-bit base address field, 
an 8-bit limit field, and an 6-bit attribute field. 
Unfortunately, tne Z8001 hardware was not available for use 
during system development. Therefore, all work to date has 
been completed tnrougn utilization of tne Z8002 
non-segmented version of the Z8000 microprocessor family 
[17J . Tne actual hardware used in tnis implementation is tne 
Advanced Micro Computers Am96/4116 MonoEoard Computer ll9j 
containing tne AmZ8002 sixteen bit non-segmented 
microprocessor. This computer provides 32K bytes of on-board 
RAM, 8k bytes of PROM/ROM space, two RS232 serial I/O ports, 
24 parallel I/O lines, and a standard INTEL Multibus 
interface. Tne general structure of tne design nas been 
preserved by simulation of the segmentation hardware in 
software. Tnis software MMU Image (see Figure 8) is created 
as a database within the Inner Traffic Controller. 
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i’igure 8. Memory Management Unit (MMU) Image 
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Tne f^MU Image is a processor-iocai database indexed by 
DER_No. Sacb DBR_No represents one record witnin tbe M!^U 
Image. Eacn record is an exact software copy of tne Segment 
Descriptor Register set in tde Hardware Each element of 
tnis software MMU Image is in tne same form utilized by tne 
special I/O instructions to load the Hardware iMMU. Each DER 
record is indexed ty segment number (Segmen t_No ) . Eacn 
Seffment_No entry is composed of three fields? Ease_Addr, 
Limit, and Attributes. Base_Addr is a i6-bit field wnicn 
contains the base address of the segment in physcal memory. 
Limit is an 8-bit field tnat specifies tne number of 
contiguous bloclcs of memory occupied by tne segment. 
Attributes is an 8-bit field representing tne eight flag's 
which specify the segment's attributes (e.g., "read”, 
"execute”, "write", etc.). 

G. SUMMARY 

An extended overview of the current SASS design has been 
presented in this chapter. The four major levels of 
abstraction comprising the SASS system have been identified 
and the major components of eacn level nave been discussed. 
The extended instruction set provided by the SASS Kernel was 
also defined. With tnis bacicground, tne actual details cf 
tnis implementation will be described in chapters III and 
I?. 
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III. iMPLEMjjNTATTON ISSUES 



Issues bearing on tne implementation of process 
management and refinements made to existing modules are 
presented in tnis chapter. Process management for tne SASS 
was provided through the implementation of the Traffic 
Controller Module, the Event Manager Module, tne Distributed 
Memory Manager Module, and a Gate Keeper Stub (system trap). 
Additionally, since a demonstration/testbed was integral to 
the testing and verification of tne implementation, it was 
necessary to complete other supportive tasKs. These 
supportive tasfcs included limited Kernel database 
initialization, revised preempt interrupt handling 
mechanisms. Idle process definition and structure, and 
additional refinements to existing modules. 



A. DATABASE INITIALIZATION 

Previous vovi on SASS has relied on statically built 
databases, which proved to be sufficient for demonstration 
of a single processor, single nost supported system. In the 
current demonstration, multiple nosts are simulated, and tne 
Kernel data structures have been refined to represent a 
multiprocessor environment. Since a multiprocessor system 
was unavailable at the time of this demonstration, several 
runs” were made and traced, using different logical CPU 
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numbers, to snow tne correctness of tnis structure. Due to 
this multiprocessor representation and simulation of 
multiple nosts, tne use of statically built Kernel datata^ses 

was no longer convenient. Therefore, it became necessary to 
provide initialization routines for tne dynamic creation of 
those Kernel databases required for this implementation. 
While it was not tne intent of tnis effort to implement 
system initialization, care was talten in the writing of 
these initializing- routines so that they might be utilized 
in tne system int iaii zation implementation with, hopefully, 
minimal refinement. Database initialization was restricted 
to those databases existing in tne Inner Traffic Controller 
and the Traffic Controller. Limited elements of the Known 
Segment Table (KST) and Global Active Segment Table (G_AST) 
were also created for demonstration purposes. 

1 . Inner Traffic Controller Initialization 

A "Bootstrap Loader" Module, which logically exists 
at a higher level of abstraction within tne Kernel, was 
created to initialize the databases of the Inner Traffic 
Controller. Tnis initialization includes tne creation of: 1) 
the Processor Data Segment (PRDS), 2 ) an MMU Map, 3) Kernel 
domain stacK segments for Kernel processes, 4) allocation 
and updating of MMU entries for Kernel processes, and 5) 
Virtual Processor Table (VPT) entries. 

The PRDS was loaded with constant values that 
specify tne physical CPU ID, logical CPU ID, and number of 
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7P's allocated to tne CPU. A design decision was made to 
allocate loffical CPU ID's in increments of two (beginning 
with zero) so that they could be used to directly access 



lists indexed by CPU number. The MMU map, constructed as a 
"byte" map, was created to specify allocated and free KMU 
Image entries. 

A separate procedure, CR£ATS_STACK , was created to 
establish the Initial Kernel domain stacic conditions for 
Kernel processes. A discussion and diagram of these initial 
stacJc conditions is presented in tne next section. 
ALLOCAT£_MMU checis tne MMU Map and allocates tne next 
availabe MMU entry to the process being created. The PHDS is 
inserted in tne allocated MMU entry and the DJBR number is 
returned to the calling procedure. The DBH number (handle) 
is merely the offset of tne DBR in the MMU Image. Since tne 

ITC deals with an address rather than a handle, a procedure, 
GST_DBfi_ADDR , was created to convert this offset into a 
physical address. UPDATE_MMU_IMAGE is the procedure wnich 
creates or modifies MMU Image entries. DPDATE_MMU_IMAGE 
accepts as arguments the DBR number, segment number, segment 
attributes, and segment limits. To facilitate process 
switching and control, various process segments must possess 
the same segment number system wide. This is accomplished 
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Tne final tasic required in ITC iniiaiizaiion is tne 
creation of the VPT. The VPT header is initialized with the 
’’running" and "ready" lists pointers set to a 'nil' state, 
and the "free" list pointer set to the first entry in tne 
message table. Virtual Processor entries are inserted in the 
main body of the VPT by the UPDATE_VP_TAiiLE procedure. 
Entries are first made for tne VP's permanently bound to the 
Memory Manager and Idle processes. The VP bound to the MM 
process is ^iven a priority of 2 (hiahest), and tne Vp bound 
to the Idle process is given a priority of 0 (lowest). The 
External VP ID for both of these VP's is set to "nil" as 
they are not visible to the Traffic Controller. The 
remaining VP's allocated to tne CPU (viz., TC visible VP's) 
are then entered in the VPT with a priority of 1 
(intermediate), and tneir "idle" and "preempt" flags are 
set. The preempt flag is set for these TC visible VP's to 
insure proper scheduling by the Traffic Controller. The EBP, 
for these remaining VP's is initialized with the Idle 



process DBR. A discussion 


of "idle 


processes 


and VP's 


will 


be provided later 


in this 


Chapter . 


The External 


VP 


ID 


for 


each TC visible 


VP is 


merely 


tne offset 


of 


the 


next 



available entry in the EXTERNAL VP LIST. This External VP ID 
is entered in the VPT, and the corresponding VP ID (viz., 
VPT Entry #) is entered in the EXTERNAL VP LIST. 

Once these VPT entries nave been made, it is 
necessary to set the state of each VP to "ready” and thread 
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tnem (by priority) into tne appropriate ready list. A VPT 
threading mechanism was provided by Reitz [5j in procedure 
MAKE_READY. However, it was desired to nave a more general 
threading mechanism that could be used for other lists. 
Procedure LlST_INS£IiT was created to provide this general 
threading mechanism. LIST_INSERT is logically a "library" 
function that exists at tne lowest level of abstraction in 
tne Kernel. This function threads an object into a list 
(specified by the caller) in order of priority, and tnen 
sets its state as specified by tne calling parameters. 

Once tne "Bootstrap Loader" nas completed ITC 
initialization, it passes control to tne ITC GETWORK 
procedure to begin VP scheduling. 

2 . Traffic Controller Initialization 

The initialization routines for tne TC include 
TC_INIT, . CREATE_PROCESS , and CREATS_KST. These routines are 
called from tne Memory Manager process. Tne MM process was 
chosen to initiate these routines as it is bound to tne 
highest priority VP and will be?in running immediately after 
the Inner Traffic Controller is initialized. Procedure 
MM_ALLOCATE was written to allocate memory space for data 
structures during initialization (viz.. Kernel stacics, user 
stacks, and KST's). Memory space is allocated in blocKs of 
100 (hex) bytes. MM_AILOCATE is merely a stub of the memory 
allocating procedure desifirned by Moore and Gary (4j . 
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It was necessary to pass long lists of arguments to 
tne TC for initialization purposes. To ail in tnis passing 
of parameters, a data structure template was used. This 
template was created toy declaring the parameters as a data 
structure in both the sending and receiving procedures, and 
then imaging this structure at absolute address zero. The 
process' stacK pointer was tnen decremented cy tne size of 
the parameter data structure, and the parameters were loaded 
into tnis data structure indexed by tne stact pointer. This 
template made it very easy to send and receive lon^ argument 
lists using tne process' stacx segment. 

TC_INIT initializes tne APT header and virtual 
interrupt vector (discussed later). Each element of tne 
running list is marlced "idle", the ready and blocked lists 
are set to "nil", and the number of VP's and first VP for 
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stack in the MMU as segment number three. The user stack 
contains no information or user process initialization 
parameters (viz., execution point and address space) as ail 
processes are initialized and begin execution from the 
Kernel domain. Next, a Kernel domain stack is allocated and 
included in the MMU Image. A aesign decision was made to 
initialize the Kernel stacks for user processes with the 
same structure as the Kernel process' stacks. The rationale 
for this decision is presented in tne next section. As a 
result of this decision, it became possible to use the 
CREATE_STACK procedure in bui Id ing^ Kernel domain stacks for 
both Kernel and user prosesses. CHEATE_STACK was therefore 
used as a library function and placed in the library module 
with LIST-INSERT. 

Finally, a Known Segment Table (KST) stub is created 
to provide a means of demonstrating the mechanism provided 
by the eventcounts and sequencers for interprocess 
communication ( IPC ) and mutual exclusion. Space for the 
process' KST is created by calling MM_ALLOCATE. The KST is 
then included in the process' address space, as segment 
number two, by UPDATE_MMU_IMAGE. initial entries are made in 
the Known Segment Table by procedure CR£ATE_KST. CREaTE_KST 
makes an entry in the KST for the "root" and marks the 
remaining KST entries as "available." The Unique_ID portion 
of the root's handle (viz., upper two words) is initialized 
as -1 (for convenience) and tne G_AST entry number portion 
of the handle (viz., lowest word) is initialized with zero. 
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3. Additional Initialization ReQuirements 



As already mentioned, the (Memory Manager Process 
prepares tne arguments utilized oy TC_INIT, CR£ATE_PP.CCESS , 
and CHEATE_KST for TC initialization and user process 
creation. Additionally, tiie MM process creates a Global 
Active Segment Table (G_AST) stub utilized for demonstration 
of event data management. The G_AST stub is declared in a 
separate module (viz., the DEMO_DATABASE Module) with the 
format prescribed by Moore and Gary (4j . However, the only 
fields initialized and utilized by this implementation are 
UNI0UE_ID, SEQUENCER, INSTANCE 1, and INSTANCE 2. The 
eventcounts and sequencer fields are initialized as zero 
whenever an entry is created in the G_AST. The UNICUE_IE is 
created Just to support this demonstration and does not 
reflect the segment's unique identifier as specified by 
Moore and Gary [4j . In this demonstration, UNIOUE_IIi is 
built with the parameters passed to MM_ACTIVATE. The first 
word in UNI0UE_ID is the G_AST entry number of the segment's 
parent, and the second word is the segment's entry number 
into tne alias table. The UNI0UE_ID togetner with tne offset 
of the segment's entry in the G_AST comprise the segment 
HANDLE maintained in tne EST. Tne first entry in tne G_AST 
is reserved for the root, and is initialized with an 
Unique_ID of minus one (-1). It should be noted that any 
call to MM_ACTIVATE for a segment already possessing an 
entry in the G_AST will not effect any cnanges to that 
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entry. Tills is to insure tnat a single G_AST entry exists 
for every seernent as specifiea by lYoore and. Gary [4j . 



B. PREEMPT INTERRUPTS 

Various refinements were made in tile handlins of botn 
pnysical (nardware) and virtual (software) preempt 
interrupts, A hardware preempt is a non-vectored interrupt 
that invokes the virtual processor scneduling mechanism 
(viz., ITC GETWORK). A virtual preempt is a software 
vectored Interrupt that invokes tne user process scheduling 
mechanism (viz., TC_G£TW0RK). This implementation provides 
tne notion of a virtual interrupt that closely mirrors the 
behavior of a hardware interrupt. In particular, there are 
similar constructs for initialization of a handler, 
invokation of a handler, masking of interrupts, and return 
from a handler. As with most hardware interrupts, a virtual 
interrupt can occur only at the completion of execution for 
an "instruction,” where each Kernel entry and exit for a 
process delimit a single "virtual instruction." 

1 , Physical Preempt Handler 

•Tne pnysical preempt handler resides in tne virtual 
processor manager (viz.. Inner Traffic Controller). The 
functions it perform are: l) save tne execution point, H) 
invoke ITC GETWORK, 3) check for virtual preempt interrupts, 
4) restore the execution point, and 5) return control via 
the IRET instruction. Reitz I5j included the nardware 
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preempt nanaler in ITC GETWORK by estabiisning two entry 
points and two exit points, one for a regular call to 
GETWORK and another for the preempt interrupt. He had a 
separate procedure, TEST_PREEMPT , that was used to checi for 
the occurrence of virtual preempt interrupts. This structure 
worfcs nicely, hut it requires some means of determining how 
GETWORK was invoiced so that the proper exiting mechanism is 
used. This was resolved by incorporating a preempt interrupt 
flag in the status register blocK of every process' Kernel 
domain stacS segment. A design decision was made to 
restructure the hardware preempt handler into a single and 
separate procedure, PH"^S_PREEMPT_HANDLER . This allowed ITC 
GETWORK to have a single entry and exit point, and it did 
away witn the necessity of maintaining a preempt Interrupt 
flag in the process stacics. PKIS_PRE£MPT_PANELSR was 
constructed from the preempt handling code in GETV/OPK and 
procedure TEST_PREEMPT . TEST_PREEP!PT was deleted from the 
ITC as its functions were performed by FHYS_PRESMPT-HANELER . 

A further refinement was made to the hardware 
preempt handler dealing with the method by wnich tne virtual 
preempt handler was invoked. Reitz [5j invoiced the virtual 
preempt handler from TEST_PREEMPT oy means of tne "call" 
instruction. Since the virtual preempt handler logically 
exists at a nigner level of abstraction than the ITC, tnis 
invocation violated our notion of only allowing "calls" to 
lower or equal abstraction levels. However, this deviation 
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was necessitated by tiie absence of a virtual interrupt 
structure. Tnis problem was alleviated by creating a virtual 
interrupt vector in tPe ITC tnat is used in tne same way as 
tne Hardware interrupt vector. Tne virtual preempt was ^iven 
a virtual interrupt number (zero). Tne virtual interrupt 
Handler is tnen invoiced by means of a "jump" tnrous^ tne 
virtual interrupt vector for virtual Interrupt number 0. 
Tnis invocation occurs in tne same manner tnat tne nandlers 
for Hardware interrupts are invoked. The virtual interrupt 
vector is created by procedure CREATi’_INT_V£C. 
CREATE_INT_VEC accepts as arguments a virtual interrupt 
number and tne address of tne interrupt Handler. Tne 
creation of tne virtual preempt entry in tne virtual 
interrupt vector is accomplished at the time of the Traffic 
Controller initialization by TC_INIT. 

2 . Virtual Preemut Handler 

Tne virtual ureempt handler (VIRT_PRSE^'PT_HANLLER ) 
resides in the user process manager (viz., the Traffic 
Controller). The functions performed by VIRT_FREEMPT_EANDLER 
are: 1) determine the VP ID of the virtual pro'^essor bein? 
preempted, 2) invoke tne process scheduling mechanism (viz., 
TC_GETWORK), and 3) return control via a virtual interrupt 
return. Tne correct VP ID is obtained by calling RUNNING_VP 
in the ITC. The Active Process Table is then locked, and the 
state of tne process running on tnat VP is changed to 
"ready." At tnis time, process scnedulins is effected by 
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caliiniP TC_C-£TWORK. Once process scneduiing is compietei, 
the APT is unlociced and control is returned via a virtual 
interrupt return. This virtual interrupt return is merely a 
Jump to the PP.SEMFT_PET label in the hardware preempt 
handler (This jump emulates the action of the IRET 
instruction for a hardware interrupt return). This latel is 
the point at which the virtual preempt interrupts are 
unmasked . 

All Kernel processes are initialized to appear as 
though they are returning from a hardware preempt interrupt. 
All user processes initially appear to be returning from a 
virtual preempt interrupt. Therefore, tne initial conditions 
of a process' Kernel domain stack is largely influenced dv 
tne stack manipulation of the preempt handlers. Figure 9 
illustrates the initial Kernel domain stack structure for 
ail system processes. 

The Initial Kernel Flag Control Word (FCW) value is 
’‘ 5000 ", indicating non-segmented code, system mode of 
operation, non-vectored interrupts masked, and vectored 
interrupts enabled. The Current Stack Pointer value is set 
to the first entry in the stack (viz., SP). The IRET Frame 
is tne portion of tne Kernel stack affected by tne IRET 
instruction. The first element. Interrupt ID (set to "FFFF” ) 
is merely popped off of the stack and discarded. The next 
element. Initial FCW, is popped and placed in tne system 
Flag Control Word. Initial FCW is set to "5000" for Kernel 
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processes and (indicating normal mcae witn ail 
interrupts enabled) for user processes. Tne final element of 
tne IRET frame. Initial IC is popped off of tne stacK and 
placed in tne program counter (?C^ register. Tnis value is 
initialized as tne entry address of tne process in Question. 

The "register" entries on the stacK represent the 
initial register contents for tne process at tne beginning 
of its execution. Since tne Kernel processes (viz., and 
Idle) do not require any specific initial register states, 
their entries reflect the register contents at the time of 
staclc creation. Initial register conditions are used to 
provide initial "parameters" required by the user processes. 
This will depend largely upon tne parameter passing 
conventions of tne implementation language. Tne means for 
register initialization was provided through CREATE_PECCSSS ; 
however, the only initial register condition used for tne 
user processes in this demonstration was register #13. 
Register #13 was used to pass tne user ID/Host number of tne 
process created. This value is utilized by the user process 
in activating the segment used for inter-process 
communication between a Host's File manager and I/O 
processes. Another logical parameter passed to the user 
processes is the root segment number. This did not require a 
register for passing in tne demonstration as it is known to 
be the first entry in the KST for all processes. The W_S_P 
entry on tne stack represents tne initial value of the 



69 



normal stacK pointer. For user processes, tnis value is 
obtained wnen tne Supervisor domain stacit for tnat process 
is created. For Kernel processes, this value is set to 
"FFFF" since tney execute solely in the Kernel domain and 
have no Superivsor domain stack. The Preempt Return Point 
specifies tne address wnere control will be passed once the 
process' FP is scheduled and the "return” from ITC GETWORK 
is executed. For Kernel processes, this is tne point within 
the hardware preempt nandier where the virtual processor 
table is unlocked. For user processes, tnis is tne point 
within the virtual preempt handler where tne Active Process 
Table is unlocked. 

It is important to note that if tne APT was not 
unlocked when a user process be^an its initial execution, 
the system would become deadlocked and no further process 
scheduling* could occur. It should be further noted that the 
initial stack conditions for user processes do not reflect a 
valiji history of execution. The "normal" history of a user 
process returniniS from ITC GETWOPK after a virtual preempt 
interrupt would reflect the passinsr of control through 
SVAP_VD3R and TC_GETWORK to the point in the virtual preempt 
handler where the APT is unlocked. Another "possible" 
history could reflect the occurrence of a hardware preempt 
interrupt at the point in the virtual preempt handler where 
tne APT is unlocked. Such a history would be depicted by 
replacing the current top of the stack with the return point 
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into the hardware preempt handler (viz., at the point of 
virtual preempt interrupt unmaslcing) and an additional 
nardware preempt interrupt frame wnose IC value in the IHET 
frame is the point in tne virtual preempt handler where tne 
APT is unlocked. The current initial stack condition for 
user processes was cnosen for its ease of understanding and 
its clear depiction of the fact that tne structure of a 
Kernel domain stack is the same for both Kernel and user 
processes . 

C. IDL2 PROCESSES 

In tne SASS design, there logically exists a Kernel 
domain "idle” process for every physical processor in the 
system and a Supervisor domain "idle" process for every "TC 
visihle" virtual processor in the system. These processes 
are necessary to insure that both tne VP scheduler (viz., 
ITC GBTWORK) and the process scheduler (TC_C£TW0RK) will 
always nave some object to schedule, hence precluding any 
CPU or VP from ever having an undefined execution point. 
Since the Kernel domain Idle process performs no useful 
work, it could be included within the ITC by means of an 
infinite looping mechanism. Tne Kernel Idle process was 
maintained separately, however, as it is hoped that future 
work on SASS will provide this Idle process with some 
constructive purpose (e.^., performing maintenance 
diagnostics ) . 
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The Supervisor aonain Idle processes (nereafter referred 
to as TC Idle processes) are scneduled (bound) on VP's when 
there are no user processes awaiting scheduling. Since a TC 
Idle process performs no user constructive worlc, we do not 
want any VP executing a TC Idle process to be bound to a 
physical processor. In other words, a VP bound to a TC Idle 
process assumes the lowest system nriority (represented by 
the "idle fla^"). Therefore, any such VP will have its idle 
flag set and will not be scneduled unless it receives a 
virtual preempt interrupt. Such an interrupt will allow the 
V? to be rescheduled by the Traffic Controller. It should be 
obvious, at this point, that a TC Idle process will never 
actually befin execution on a real processor. This knowledge 
allowed a design decision to be made to only simulate the 
existence of TC Idle processes. At tne TC level, this was 
accomplished by a constant value, IDLS_PP.OC , that was used 
as a process ID in tne APT running list, thus precluding tne 
necessity of any "idle" entries in the APT. At the ITC 
level, any VP marlted "idle" (viz., tne idle flag set) was 
given tne DPR number (viz., address space) of the Kernel 
Idle process solely to provide tne use of a Kernel domain 
stacK for rescheduling of the VP. 

D. additional KERNEL REFINEMENTS 

In addition to those already discussed, several other 
refinements to existing Kernel modules were effected in this 
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irrplementa ti on . One of inese refinerrents deals witn tne way 
virtual processors are identified fcy tne Traffic Controller. 
In the current inplenentati on , all TC visible virtual 
processors are ^iven an External VP ID which corresponds to 
its entry nurrher in an External VP List. This required a 
modification to the ITC procedure PUNNING_VP. The benefits 
derived from this refinement included the ability to 
directly access the External VP ID in tne Virtual Processor 
Table vice the requirement of a run time division to compute 
its value and the ability to use the External V? ID as an 
index into the TC running list. 

Refinements were also made to the existing Memory 
manager. File Manager, and 10 process stubs used for 
demonstration purposes. These refinements were largely 
associated with tne eventcount and sequencer mecnanisms 
utilized in this implementation. The current status of these 
processes is provided in a report by Scneil and Cox [22J . 

The remaining refinements deal largely with the MMU 
Image. In Moore and Gary's [4J design, tne MMU Image was 
managed by the Memory Manager process. This was largely 
because tne MMU Image is a processor local database and 
would seem well suited for management by the non-di stri buted 
Kernel. In fact, tne MMU Image is utilized mainly by tne ITC 
for the multiplexing of process address spaces. Therefore, 
in the current design, tne MMU Images are maintained by the 
Inner Traffic Controller. However, the MMU header proposed 
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by I^oore ana Gary (vi 2 .. tae BLCCKS_USED ana 
biAXlMU^’_AVAI LAELE_^EL0CSS t’ieias) was retained in the Memory 
Manarer as it is usea strictly in tne management of a 
process' virtual core and is not associated with the 
hardware MMU . 

In ’'^ells' design [6J , the Traffic Controller used tne 
linear ordering of tne DER entries in the MMU Image as the 
DSR handle (viz., 1,2,3...). This required a run time 
division operation to compute the DBR number, and a run time 
multiplication operation, by MM_GET_DBR_VALUE , to recompute 
the EER address for use by the ITC. In the current design, 
the offset of the EER entry in the MMU Image (obtained at 
the time of MMU allocation) is used as tne EER handle in the 
Traffic Controller. Furthermore, SWAF_VESR was refined to 
accept a EER handle rather than a EER address to preclude 
the necessity of the Traffic Controller having to deal with 
MMU addresses. EER addresses are computed only within the 
ITC (viz., by procedure GET_EER_AEER ) by adding the value of 
the EER handle to the base address of the MMU Image. Since 
EER addresses are now used solely within tne ITC. procedure 
MM_GET_EER_V ALUE was no longer needed and was deleted from 
the Memory Manager. 

E. summary 

The primary issues addressed in this thesis effort have 
been presented in this chapter. Aside from the process 
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niandiPement functions, tnis description included a mecnanism 
for limited Kernel dataoase initialization, a revised 
preempt interrupt Handling mecnanism, tne creation of a 
virtual interrupt structure, a definition of "idle" 
processes and tneir structure, and a discussion of tne minor 
refinements effected in existing SASS modules. A detailed 
description of tne implementation of process management 
functions for tne SASS is presented in tne next chapter. 
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17. PROCESS MANAGEMJiiNT IMPLEMENTATION 



Tiie implementation of process management functions and a 
gate deeper stub (system trap) is presented in tnis cnapter. 
Tne implementation is discussed in terms of tne Event 
Manager, Traffic Controller, Distributed Memory Manager, 
User Gate, and Kernel Gate Keeper modules. A tloclc diagram 
depicting tne structure and interrelationsnips of these 
modules is presented in figure 10. Support in developing tne 
ZS000 machine code for tnis implementation was provided by a 
Zilog MCZ Developmental System operating under the RIO 
operating system. The Developmental System provided dislc 
file management for a dual drive, hard sectored floppy disic, 
a line oriented text editor, a PLZ/ASM assembler, a linker 
and a loader tnat created an executable image of each Z80OO 
load module. An upload/d ownload capability with tne 
Am96/4116 MonoBoard computer was also provided. This 
capability, along witn tne general interfacing of tne 
Am96/4:116 into the SASS system, was accomplished in a 
concurrent tnesis endeavor by Gary Baker. Baker's work 
relating to hardware initialization in SASS. will be 
published upon completion of nis tnesis work in June 1981. 
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A. EVENT MANAGER MODULE _ 

The eventcouni and sequencer primitives Ll5J , which are 
system-wide oDjects, collectively comprise the event data of 
SASS. As mentioned earlier, this event data is tied directly 
to system segments and is stored in the Global Active 
Segment Table. There are two eventcounts and one sequencer 
for every segment in the system. These objects are 

identified to the Kernel in user calls by specification of a 
segment number. Once this segment number is identified by 
the Kernel, tne segment's handle can be obtained from tne 
process' Known Segment Table. The segment handle identifies 
the particular entry in tne G_AST containing tne event data 
desi red . 

Tne Event Manager module manages tne event data within 
the system and provides tne mecnanism for interprocess 
communication between user processes. The Event Manager 
consists of six procedures. Four of these (Advance, Await, 
Read, and TicKet) represent tne four user extended 
instructions provided by the Event Manager. The remaining 
two procedures provide internal computational support to 
include necessary security cneclcing. The Event Manager is 
invoked solely by user processes, via tne Gate Keeper, 
through utilization of the extended instruction set 
provided. For every Event Manager extended instruction 
invoiced by a user process, the non-discretionary security is 
verified by comparing the security access classification of 
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tne process invoking tne instruction witn tne classification 
of tne object (segment) being accessed. Access to the user 
process' Known Segment Table is required by tne module in 
order to ascertain tne segment nandle and security class for 
a ffiven sesment number. The PLZ/ASM assembly language 
listing for tne Event ^'anager module is provided in Appendix 
A. A more detailed discussion of tne procedures comprising 
tne Event Manager follows. 

1 . Support Procedures 

The procedures GET_HANEL£ and CON VERT_AND_V£EIIY 
provide internal support for tne Event Manager anc are not 
visible to tne user processes. Procedure CONVEP.T_AND_VEF.IFY 
is invoked by tne four procedures representing the 
instruction set of the Event Manager. The input parameters 
to CON^SP,T_AND_VEP. IFT are a segment number and a requested 
mode of access (viz., read or write). CON VERT_AND_VER1FY 
returns a pointer to tne segment's handle and a success 
code. Procedure GET_HANDLE is invoked solely by 
CON VERT_AND_VEP IFT . The input parameter to GET_HANDLE is the 
segment number received as input by CONVERT_AND_VERIFY . 
GET_HANDLE returns a pointer to tne segment's handle, a 
pointer to tne segment's security classification, and a 
success code. A discussion of tne functions provided by 
these support procedures follows. 

Procedure GET_HANDL.E translates tne segment number, 
received as input, into a EST index number and verifies that 
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tne resuiiin,^ index number is valid. Next tne base address 
of tne process' KST is obtained from procedure 
ITC_GET_SEG_PTR. Tne KST index number is tnen converted into 
a KST offset value and added to tne base address to obtain 
tne appropriate KST entry pointer for tne se,£rment in 
question. A verification is tnen made to insure that tne 
referenced seg’ment is "icnown" to tne process. If tne segment 
is not Known, an error message is returned to 
CONVKRT_AND_VERIFY. Otnerwise, a pointer to tne se,?ment's 
nandle is obtained to identify tne segment to tne memory 
manager. A pointer to tne segment's security class entry in 
the KST is also returned for use in appropriate security 
cnecKs . 

Procedure CONVERT_AND_YERIFY provides tne necessary 
non-discretionary security verification for tne extended 
instruction set of the Event Manager. Procedure GET_HANDLE 
is invoiced for segment number verification and to obtain 
pointers to the segment's handle and security class. If 
G£T_HANDLE returns witn a successful verification, tne 
process' security class is compared to tne segment's 
security class to verify tne mode of access requested. A 
request for "write" access causes invocation of tne CLASS_E0 
function in tne Non-Di scretionary Security Module to insure 
that the security classification of tne process is equal to 
the classification of the eventcount or sequencer, which is 
the same as that of tne segment. Otnerwise, tne CLASS GE 



function is called to verify tnat tne process Has read 
access. If tne appropriate security cnecK is unsuccessful, 
an error code is returned by CONVSP.T_AND_ VERIFY . Otherwise, 
tne segment handle is returned along with a success code of 
"succeeded" indicating that tne user process possesses the 
necessary security clearance to complete execution of tne 
extended instruction. 

2. Read 

Procedure READ ascertains tne current value of a 
user specified eventcount and returns its value to the 
caller. Tne input parameters to READ are a segment number 
and an instance (viz., an event number). CONVERT_AND_?ERIFT 
is invoiced with a "read" access request to obtain tne 
segment's handle and necessary verification. "Read" access 
is sufficient for tnis operation as it only requires 
observation of tne current eventcount value and performs no 
data modification. If verification is successful, procedure 
MM_READ_EVSNTCOUNT is called to obtain the eventcount value. 

3. Ti cKet 

Procedure TICKET returns tne current sequencer value 

for the segment specified by the user. C0NVERT_ANE_VER1FY is 

called with a request for write access to obtain 

verification and the segment nandle. Write access is 

required because once tne sequencer value is read it must be 

incremented in anticipation of the next ticicet request. Once 

■% 

verification is complete, MM_TICKET is invoiced to obtain the 
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sequencer value that is returned to tne user process. It is 
noted tnat every call to TICKET for a particular segment 
number will return a unique and time ordered sequencer 
value. This is because tne sequencer value may oniy oe read 
within M^'_TICKET while the G_AST is Incited, thereby 

preventing simultaneous read operations. Futhermore, once 
the sequencer value is read it is incremented before the 
G_AST is unloclted. 

4. Await 

Procedure AWAIT allows a user process to blocfc 
itself until some specified event has occurred. The 
parameters to AWAIT include a segment number and instance, 
which identify a particular event, and a user specified 
value which identifies a particular occurrence or the event. 
Verification of read access and a pointer to tne segment's 
handle is obtained from procedure CONV£RT_AND_VEHIFY . 
Procedure TC_AWAIT is invoiced to effect the actual waiting 
for the event occurrence. TC_AWAIT will not return to AWAIT 
until the requested event has occurred. It is noted that 
AWAIT maKes no assumptions about the event value specified 
by the user. Therefore, the Kernel cannot guarantee that the 
event specified by the user will ever occur, this is the 
responsibility of other cooperating user processes. 

b. Advance 

Procedure AL'VanCE allows a user process to broadcast 
the occurrence of some event. This is accomplished by 
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incremeiuing tne value of me evenicount associaiea witn me 
event tnat has occurred. The parameters to ADVANCE include a 
segment number and instance wnicn identify a particular 
event. The calling process must nave write access to the 
identified segment as modification of the eventcount is 
required. Verification of write access and a pointer to tne 
segment's handle is obtained through procedure 
CON VERT_AND_'/ERIFY . Procedure TC_ADVANCE is invoiced to 
perform the actual broadcasting of event occurrence. 

E. traffic controller module 

The primary functions of the Traffic Controller module 
are user process scheduling and support of tne inter-process 
communication mechanism. The Traffic Controller is invoiced 
by tne occurrence of a virtual preempt interrupt and ty tne 
Event Manager and the Segment Manager through tne extended 
instruction set: TC_Advance , TC_Await, Process_Class ♦ and 
Get_DER_NUMBSR. The Traffic Controller module is comprised 
of nine procedures. Four of these procedures represent tne 
extended instruction set of tne Traffic Controller. A 
detailed discussion of six of tne proceaures contained in 
the Traffic Controller module is presented below. The 
remaining three procedures (viz., TC_INIT, CREATE_?RCCESS , 
and CREATE_KST) were described in chapter three. The PLZ/ASM 
assembly language source code listings for tne Traffic 
Controller module is provided in Appendix £. 
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1 . TC Geiworb: 



Procedure TC_GETWOEK provides me mecnanism for user 
process scdedulin^. Tiie input parameters to TC_GSTWORK are 
tne VP ID of tne virtual processor to vnicn a process will 
be scheduled and the logical CPU number to which the virtual 
processor belongs. The determination of wnicn process to 
schedule is made by a looping mechanism that finds the first 
"ready" process on the ready list associated with the 
current logical CPU number. Processes appear in the ready 
list by order of priority. This looping mechanism is 



required as both running and ready processes are 
maintained on the ready list. This ready list structure was 
Chosen to simplify tne algorithm provided in procedure 
TC^Advance. If a ready process is found, its state is 
Changed to "running" and its process ID (viz., tne APT entry 
number) is inserted in tne running list entry associated 
with tne current virtual processor. Procedure S'>IAP_VDBR is 
then invoiced in the Inner Traffic Controller to effect the 
actual process switch. If a ready process was not found 
(viz., the ready list was empty or comprised solely of 
"running processes"), tnen tne running list entry associated 
with the current virtual processor is mariced with the 
constant ”ldie_Proc" and procedure IDLE is invoiced in tne 
Inner Traffic Controller. 
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2 . TC Await 



Tue primary function of TC_AWAIT is tne 
determination of wtietiier some user specified event nas 
occurred. If tne event nas occured, control is returned to 
tne caller. Otnerwise, tne process is Oiocied and anctner 
process is scneduled. Tne input narameters to TC_AWAIT are a 
pointer to a segment nandlet an instance (event number), and 
a user specified eventcount value. TC_AWAIT initially locks 
tne Active Process Table and obtains tne current value of 
tne eventcount in question by calling procedure 
MM_RSAD_S?ENTCCUNT . The determination of event occurrence is 
made by comparing tne user specified eventcount value witn 
the current eventcount. If tne user value is less tnan cr 
equal to tne current eventcount, tne awaited event nas 
occurred and control is returned to tne caller. Otnerwise, 
tne awaited event nas not yet occurred and tne process must 
be blocked. 

If the process is to be blocked, procedure 
RUNNING_VP is invoked to ascertain tne VP ID of tn® virtual 
processor bound to tne process. Tne process' ID (viz., APT 
entry number) is tnen read from the running list. Tne input 
parameters to TC_A'jIAIT (viz.. Handle, Instance, and Valued 
are then stored in tne Event Data portion of me process' 
APT entry. Tne process is removed from its associated ready 
list by redirecting the appropriate linking threads 
(pointers). Once removed from tne ready list, tne process is 
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threaded into the biocJced list and its state changed to 
"biociced” by invocation of the library function LIST_INSERT. 
Procedure TC_GfiTWORK is then called to schedule another 
process for the current virtual processor. 

3. TC Advance 

The primary purpose of TC_ADVANCE is the 
broadcasting of some event occurrence. This entails 
incrementing the eventcount associated with the event, 
awakening ail processes that are waiting for the event, and 
insuring proper scheduling order by generating any necessary 
virtual preempt interrupts. Tne nign level design algorithm 
for TC_ADVANCE is provided in figure 11. The input 
parameters to TC_ADVANCE are a pointer to a segment's handle 
and an instance (event number). Initially, TC_AD?ANCE locks 
tne APT to prevent tne possibility of a race condition. Tne 
eventcount identified by the input parameters is then 
incremented by calling MM_ADVANCE. MM_ADVANCS returns tne 
new value of the eventcount. Once the eventcount has been 
advanced, TC_ADVANCE awakens all processes awaiting tnis 
event occurrence. This is accomplished by checking all 
processes that are currently in tne blocked list. The 
process' HANDLE and INSTANCE entries are compared with the 
handle and instance identifying tne current event. If tney 
are the same, then tne process is awaiting some occurrence 
of tne current event. In sucn a case, tne process' VALUE 
entry in the APT is compared with the current value of the 
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TC_ADVANCL‘ Procedure (HANDLE, INSTANCE) 
Ee^in 

! Get new eventcount ! 

COUNT := MM_AUyANCE (HANDLE, INSTANCE) 

Cali WAIT.LOCK (APT) 

! VaAe up processes ! 

PROCESS := BLOCKED LIST HEAD 



Do wniie not end of BLOCKED_LIST 
If (PROCESS. HANDLE = HANDLE) and 

(PROCESS . INSTANCE = INSTANCE) and 
(PROCESS .COUNT <= COUNT) 
then 

Call LIST_INSERT(READI LIST) 
end i f 

PROCESS ;= PROCESS .NEXT_PROCESS 
end do 

! Cnect ail ready lists for preempts ! 
LOGICAL_CPU_NO := 1 

Do wniie LOGICAL_CPU_NO <= #NR_CPU 
! Initialize oreempt vector ! 
yP_ID := nRST_VP(LOC-ICAL_CPU_NO ) 

Do for LOOP := 1 to NR_7P( LOGICAL_CPU_NO 
RUNNING_LIST[VP_IDj .PREEMPT := #TRUE 

VP_ID := VP_ID + 1 
end do 

! Find preempt candidates ! 

CANDIDATES := 0 

PROCESS := READY LIST HEAD (LOGICAL CPU NO) 



Figure 11 
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VP_ID := FIRST_VP{LOGICAL_CPU_NO) 

Do (for CYCLD = 1 lo NR_VP (LOGICAL CPU NO) 
non end of READr_LIST(LCGICAL_CPU_NO) 

If PROCESS = #RUNNING 
then 

HUNNING_LIST17P_IDJ .PREEMPT := *#FALSE 
else 

CANDIDATES := CANDIDATES 1 
end i f 

yp_ID := VP_ID + 1 
PROCESS := PROCESS. NEXT_PROCESS 
end do 

! Preempt appropriate candidates ! 

7TJ_ID := FIRST_VP(LOGICAL_CPU_NO) 

Do for CHECK := 1 to NR_7P (LOGI CAL_CPU_NO > 
If (RUNNING LIST[7P_IDJ .PREEMPT = #=TRUE ) 
(CANDIDATES > 0) 
tnen 

Call SET_PREEMPT(7P_ID) 

candidates := CANDIDATES - 1 
end i f 

VP_ID := 7P_ID + 1 
end do 

L0GICAL_CPU_N0 := LOGI CAI_CPU_NO + 1 
end do 

Call UNLOCK(APT) 

Return 

End TC ADVANCE 



Figure li. TC_AD7ANCE Algoritnm (Continued) 
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eventcount. If tne process' VALUE is less tnan or equal to 
tne current eventcount value, tne awaited event nas occurred 
and tne process is removed from tne Dlocired list and 
tnreaded into the appropriate ready list ty tne litrary 
function LIST_INSERT. 

Once tne bloclced list nas been checied, it is 
necessary to reevaluate eacn ready list to insure tnat tne 
nignest priority processes are running. It is relatively 
simple to determine if a virtual preempt interrupt is 
necessary, nowever, it is considerably more difficult to 
determine whicn virtual processor snould receive the virtual 
preempt. To assist in this evaluation, a "count" variable 
(number of preempts needed) is zeroed and a preempt vector 
is created on the Kernel stacit with an entry for every 
virtual processor associated with tne logical CPU being 
evaluated. Initially, every entry in tne preempt vector is 
marlced "true" indicating tnat its associated virtual 
processor is a candidate for preemption. Once the preempt 
vector is initialized, tne first ”n” processes on tne ready 
list (where n equals the number of VP's associated with the 
current logical CPU) are checked for a determination of 
their state. If a process is found to be "runnins-" then it 
should not be preempted as processes appear in tne ready 
list in order of priority. When a running process is found, 
its associated entry in tne preempt vector is marked 
’false.” If a process is encountered in tne "ready” state 
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variable is 



then it should be running and the "count" 
incremented. Wnen tne first "n" processes nave been cnecited 
or when we reach the end of the current ready list 
(whichever comes first), the entries in tne preempt vector 
are "popped” from tne stacic. If an entry from the preempt 
vector is found to be "true”, this indicates that its 
associated virtual processor is a candidate for preemption 
since it is either bound to a lower priority process, or it 
is "idle." In such a case, tne "count” variable is evaluated 
to determine if the virtual processor associated with the 
vector entry should be preempted. If tne count exceeds zero, 
a virtual preempt interrupt is sent to the V? and the count 
is decremented. Otherwise, no preempt is sent as tnere is no 
higher priority process awaiting scheduling. 

This preemption algorithm is completed for every 
ready list in the Active Process Table. Once all ready lists 
nave been evaluated, tne APT is unlocked and control is 
returned to tne caller. It is noted that it is not necessary 
to invoke TC_GETWORK before exiting ADVANCE. If tne current 
V? requires rescheduling, it will have received a virtual 
preempt interrupt from tne preemption algorithm. If this nas 
occurred, the VP will be rescheduled wnen its running 
process attempts to leave tne Kernel domain and tne virtual 
preempt interrupts are unmasJced. 
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Virtual Preempt Handler 



VIRTUAL_PREEMPT_HANDLER is tne interrupt Handler for 
virtual preempt interrupts. The entry address of 
VIRTUAL_PREEMPT_HANDLER is maintained in the virtual 
interrupt vector located in the Inner Traffic Controller. 
Once invoked, the handler locks the Active Process Table and 
determines which virtual processor is beinfi- preempted by 
calling RUNNING_VP. The process running on tne preempted VP 
is then set to the "ready” state and TC_GETWORE is invoked 
to reschedule tne virtual processor. When TC_GETWORK returns 
to VIRTUAL_PREEMPT_HANDLER, the APT is unlocked and a 
virtual Interrupt return is executed. This return is simply 
a jump to the point in the hardware preempt handler where 
the virtual interrupts are unmasked. This effects a virtual 
interrupt return instruction. 

5. Remaining Procedures 

The remaining two procedures in tne Traffic 
Controller module represent the extended instructions: 
PROCESS_CLASS and GET_DBR_NUMBER . Both procedures lock the 
Active Process Table and call RUNNING_VP to determine which 
virtual processor is executing the current process. The 
process ID (viz., APT entry Number) is then extracted from 
the running list. PROCESS_CLASS reads and returns the 
current process' security access classification from the 
APT. GET_DBR_NUMBER reads and returns tne current process' 
DBR handle. It should be noted that in general the DER 
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number provided by procedure GET_DBR_NUMBEH is only valid 
while the APT is locked. Particularly, in the current SASS 
implementation, the Segment Manager invokes GET_DBE_NUMSER 
and then passes the obtained DBP. number to the Distributed 
Memory Manager for utilization at that level. In a more 
general situation, the process associated with the DBR 
number may nave been unloaded before the DBR number was 
utilized, thus making it invalid. This problem does not 
arise in SASS as all processes remain loaded for tne life of 
the system. 

C. DISTRIBUTED MEMORY MANAGER MODULE 

The Distributed Memory Manager module provides an 
interface between the Segment Manager and the Memory Manager 
process, manipulates event data in tne Global Active Segment 
Table (G_AST), and dynamically allocates available memory. A 
detailed description of tne Distributed Memory Manager 
interface to the Memory Manager process was presented by 
Wells [6]. The remaining extended instruction set is 
discussed in detail below. The complete PLZ/ASM source 
listings for the Distributed Memory Manager module is 
provided in Appendix C. 

1 . MM Read Eventcount 

MM_READ_E7ENTC0UNT is invoked by the Event Manager 
and tne Traffic Controller to obtain tne current value of 
the eventcount associated with a particular event. The input 
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parameters to tnis procedure are a segment nandie pointer 
and an instance (event Number), wtiicn togetner uniquely 
identify particular event. 

The (x_AST is locJred and the entry offset of me 
segment into the G_AST is obtained from the segment's 
handle. The instance parameter is then validated to 
determine which eventcount is to be read. If an invalid 
instance is specified, control is returned to the caller 
specifying an error condition. Otherwise, the current value 
of the specified eventcount is read. The G_AST is then 
unlocked, and the current eventcount value is returned to 
tne caller. 

2. MM Advance 

MM_AEVANCE is invoiced by the Traffic Controller to 
reflect the occurrence of some event. The input parameters 
to MM_ADVANCE are a pointer to a segment's handle and a 
particular instance (event number). 

The Global Active Segment Table is locKed to prevent 
a race condition, and the offset of the segment's entry into 
the G_AST is obtained from the segment handle. The instance 
parameter is then validated to determine which eventcount is 
to be advanced. If an invalid instance is specified, an 
error condition is returned to the caller and no data 
entries are affected. If the instance value is valid, the 
appropriate eventcount is incremented, and its new value is 
returned . 
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3. MH Ticfcet 



MM_TICKET is Invoicea ty tHe Event Manager to obtain 
tne current value of the sequencer associated witn a 
specified segment. Tne input parameter to MM_TICKET is a 
pointer to a segment's handle. 

Initially, MM_TICKET loots tne Global Active Segment 
Table to prevent a race condition. Next the offset of the 
segment's entry into the G_AST is obtained from tne segment 
handle. The current value of the sequencer for the specified 
segment is then read and saved as a return parameter to the 
caller. The sequencer value is then incremented in 
anticipation of tne next ticlcet request. Once this is 
complete, the G_AST is unloclced and control is returned to 
the caller. 

-• MM Allocate 

The MM_ALLOCATE procedure provided in this 
implementation is a stub of tne MM_ALLOCa.TE described in tne 
Memory Manager design of Moore and Gary [4j . 

The primary function of MM_ALLOCATE is tne dynamic 
allocation of fixed size biocts of available memory space. 
It is invotea in tne current implementation by tne 
initialization routines in B00TSTRAP_L0A0ER and TC_INIT for 
the allocation of memory space used in tne creation of tne 
Kernel domain and Supervisor domain stacic segments and the 
creation of the Known Segment Tables for user processes. 
Dynamic reallocation of previously used memory space (viz., 
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gavba.ge collection) is not proviiea by tne MM_AILOCATS stub 
in tnis implementation. All memory allocation required in 
tnis implementation is for segments supporting system 
processes tbat remain active, and tnus allocated, for tne 
entire life of tne system. Memory is allocated in biocits of 
256 (decimal) bytes of processor local memory (on-board 
RAM). In tnis stub allocatable memory is declared at compile 
time by a data structure (MZM_POOL) tbat is accessible only 
by MM_ALLOCATE. 



The input parameter to MM_AILOCATE is the number of 
blocJcs of requested memory. Tnis parameter is converted from 
a bloclt size to the actual number of bytes requested. This 
computation is made simple since memory is allocated in 
powers of two. The byte size is obtained by logically 
shiftlns left the input parameter ei^bt times, where eight 
is the power of two desired (viz., 256 ). Once tne size of 
the requested memory is computed, it is necessary to 
determine tne starting address of tne memory blocir(s) to be 
allocated. To assist in this computation, a variable 
(NEXT_BLOCK) is used to fceep tracic of tne next available 
bloci of memory in MEM_POOL. NEXT_BLOCK, which is 
initialized as zero, provides tne offset into tne memory 
being allocated. Once the starting address is obtained, the 
physical size of tne memory allocated is added to NEXT_BICCS 
so that the next request for memory allocation will begin at 
the next free byte of memory in MEM_POOL. This new value of 
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NEXT_BLOCK is saved and tne starting address of me memory 
for tnis request is returned to tne caiier. 



D. GATB KEEPER MODULES 



The 


SASS 


Gate Keeper provides 


the 


logi 


cal boundary 


between 


tne 


Supervisor and tne 


Kernel 


and 


isolates tne 


Kernel from 


the system users, thus 


maAine- 


i t 


tamperproof . 


Tni s is 


accomplished by means of tne nardw 


are 


system/normal 


mode and 


the 


software rine-crossi n? 


mechanism 


provided by 



tne Gate Keeper. Tne Gate Keeper is comprised of two 
separate modules: l) tne USER_GATE module, and 2) tne 
KERNEI_GATE_KEEPER module. Tnese modules are disjoint, witn 
the USER_GATE module residing in the Supervisor domain and 
tne KERNEL_GATE_KEEPER module residing in tne Kernel domain. 
It is important to note tnat the USER_GATE is a separately 
linKed component in tne Supervisor domain and is not liniied 
to the Kernel. The only tning in common between tnese two 
modules is a set of constants identifying tne valid extended 
instruction set which tne Kernel provides to tne users. 

The Gate Keeper modules presented in tnis implenemtation 
are only stubs as they do not provide all of the functions 
required of the Gate Keeper. Rowever, the only tasA not 
provided in this implementation is the validation of 
parameters passed from the Supervisor to the Kernel. A 
detailed description of this parameter validation design is 
provided by Coleman [3j . In the process management 
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demonstration, tne Supervisor stuns are written in PLZ/ASM 
witH all parameters passed by CPU registers. A detailed 
description of the Gate Keeper modules and the nature cf 
their interfaces is presented below. The PLZ/ASM source 
listings for the two Gate Keeper modules are provided in 
Appendix B. 

1 . User Gate Module 

The USER_GAT^: module provides the interface 
structure between tne user processes in tne Supervisor 
domain and the Kernel. The USER_GATE is comprised of ten 
procedures (viz., entry points) tnat correlate on a one to 
one basis with the ten "user visible" extended instructions 
(listed in figure 6) provided by the Kernel. The only action 
performed by each of these procedures is the execution of 
the "system call" instruction (SC) with a constant value. 
Identifying the particular extended instruction invoked, as 
the source operand. 

The SC instruction is a system trap tnat forces tne 
hardware into the system mode (Kernel domain) and loads 
register 15 with the system stacx pointer (Kernel domain 
staclc). The current instruction counter value (IC) is pushed 
onto the Kernel stacJc along with tne current CPU flag 
control word (PCW). In addition, the system trap instruction 



is pushed 


onto 


tne 


Kernel staclr with tne upper 


byte 


representing 


the 


SC 


instruction and the lower 


byte 


representing 


tne 


SC i 


nstruction's source operand (viz. 


, tne 
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Kernel extended instruction code). Togetner, tr.ese 
operations form an interrupt return (IRET^ frame as 
illustrated in figure 9. Once tnis is complete, tne ECW is 
loaded witn tne FCW value found in tne System Call frame of 
the Program Status Area (viz., tne hardware "interrupt 
vector"). Tne structure of tne Program Status Area is 
illustrated in figure 12 , Tne instruction counter is then 
loaded with the address of the SC instruction trap nandler. 
This value is also located in the SC frame of the Program 
Status Area. 

2. Kernel Gate Keeper Module 

The system trap nandler for the System Call 
instruction is the KERNEI_GATE_KEEPER . The address of the 
KERNEL_GATE_KEEPER and the Kernel FCW value are placed in 
the System Call frame of tne Program Status Area hy the 
BOOTSTRAP_LOADER module during initialization. The 
KERNEL_6ATE_KEEPER fetches the extended instruction code 
from the trap instruction entry in the IHET frame on the 
Kernel stack. This value is then decoded hy a "case” 
statement to determine which exiendeli instruction is to be 
executed. If the extended instruction cod^ is valid, the 
appropriate Kernel procedure is invoked. Otherwise, an error 
condition is set and no Kernel procedures are not invoked. 
Once control returns to tne KERNEI_GATE_KEEPER , the CPU 
registers and normal stack pointer (NSP) value are pushed 
onto tne Kernel stack in preparation for return to tne 
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NOTE: Offsets represent Program Status Area structure 
for non-s egmented ZEi.^2 microprocessor. 



Figure 12. Program Status Area 
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Supervisor domain. It is noted tnat tnis operation would 
normally occur immediately upon entry into tne 
£ERNi)L_GATS_KiiEP]SR . In tdis implementation, aowever, 
parameter validation is not accompl isded and tne CPU 
registers are used to pass parameters to and from tne Kernel 
only for use by the process manaeement demonstration. In an 
actual SASS environment, all parameters would be passed in a 
separate argument list and tne CPU registers would appear 
exactly tne same upon leaving tne Kernel as tney did upon 
entering tne Kernel. TMs is important to insure that no 
data or information is leaked from the Kernel by means of 
the CPU registers. 

Control is returned to tne Supervisor by means of tne 
return mechanism in the hardware preempt hanaler. This 
mechanism is utilized to preclude tne necessity of building 
a Separate mechanism for the KERNEI_GATS_KEEPER that would 
actually perform tne very same function. To accomplish this, 
the KERNEL_GATE_KEEPER executes an unconditional jump to the 
PREEMPT_RET label in PHYS_PREEMPT_HANDLER . This "jump" to 
the hardware preempt handler represents a "virtual IRET" 
instruction providing tne same function as tne virtual 
interrupt return described in the discussion of tne virtual 
preempt handler. At this point, tne virtual preempt 
interrupts are unmasked, tne normal stack pointer and CPU 
registers are restored from tne stack, and control is 
returned to the Supervisor by execution of the IRET 
instruction. 
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E. SUMMARY 



Tne implerreiua tior* of process rranaseme 
tne SASS nas teen presented in i 
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V. CONCias TON 



The implementation of process management for the 
security Kernel of a secure arcnival storage system nas teen 
presented. The process management functions presented 
provide a logical and efficient means of process creation, 
control, and scheduling. In addition, a simple but effective 
mecnanism for inter-process communication, based on tne 
eventcount and setiuencer primitives, was created. Work was 
also completed in tne area of Kernel database initialization 
and a Gate Keeper stub to allow for dual domain operation. 

Tne design for tnis implementation was based on tne 
Zilog Z8001 sixteen bit segmented microprocessor [l7J used 
in conjunction witn tne Zilog 28010 f^emory (management Unit 
[18]. The actual implementation of process management for 
the SASS was conducted on the Advanced (micro Computers 
Am98/4116 fionoBoard Computer fl9| featuring tne AmZS002 
sixteen bit non-seemented microprocessor. Ses-men tat ion 
hardware was simulated by a software (Memory Management Unit 
Imase . 

Tnis implementation was effected specifically to support 
the Secure Archival Storage System (SASS) [21] . However, tne 
implementation is based on a family of Operating Systems [ij 
designed with a primary goal of providing multilevel 
information security. Tne loop free modular design utilized 
in this implementation easily facilitates any required 
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expansion or modification for otner family memcers. In 
addition, tnis implementation fully supports a 
multiprocessor design. Wnile tne process management 
implementation appears to perform correctly, it nas not been 
subjected to a formal test plan. Sncn a test plan snould be 
developed and implemented before Kernel verification is 
begun . 

A. FOLLOW ON WORK 

Tnere are several possible areas in tne SASS aesign tnat 
would be immediately suitable for continued research. In tne 
area of Hardware, tnis includes, tne establishment of a 
multiprocessor environment, hardware ini tiali za tion , and 
interfacing to tne host computers and secondary storage. 
Further worK in tne Kernel includes tne actual 
implementation of the memory manager process, and the 
refinement of tne Gate Keeper and Kernel intiali zat ion 
structures. The implementation of tne Supervisor has not 
been addressed to date. Its areas of research include the 
implementation of the File Manager and Input/Cutput 
processes, and tne final design and implementation of tne 
SASS-Hosts protocols. 

Otner areas tnat could also prove interesting in 
relation to tne SASS include tne implementation of dynamic 
memory management, tne support of multilevel nosts, dynamic 
process creation and deletion, and the provision of 
constructive wortt to be performed by tne Idle process. 



APPENDIX A 



EVENT MANAGER LISTINGS 



Z80fe)0ASM 2.0ii 

LOG OBJ CODE STMT SOURCE STATEMENT 
UISTON ?TTT 
EVENT MGR MODULE 



CONSTANT 

TRUE := 1 

FALSE := 0 

READ_ACCESS := 1 

WRITE_ACCESS := 0 

SUCCEEDED := 2 

SEGMENT_NOT_KNOWN := 28 

ACCESS_CLASS_NOT_EO := 33 

ACCESS_CLASS_NOT_GE := 41 

KST_SEG_NO := 2 

N?._0F_KSEGS := 10 

MAX_NO KST ENTRIES := 54 

NOT KNOWN ■ := %FF 



T'^PE 

H_ARRAY ARRAY [3 WORD] 

KST_REC RECORD 
[MM_HANDLE H_ARRAY 

SIZE WORD 

ACCESS_MODE BYTE 

IN_CORE BYTE 

CLASS LONG 

M_SEG_NO SHORT_INTEGER 
ENTRY_NUMBSR SHORT_INTEGER 

J 

EXTERNAL 

MM_TICKET PROCEDURE 

m READ_EVSNTCOUNT PROCEDURE 
TC“ADVANC£ procedure 

TC_AWAIT PROCEDURE 

PROCESS CLASS PROCEDURE 
CLASS_E5 PROCEDURE 

CLASS_GE PROCEDURE 

ITC GET SEG PTR PROCEDURE 
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INTERNAL 

SSECTION Er_fCST_DCL 

! NOTE: THIS SECTION IS AN "OVERLAY" 

OR "FRAI^E" used TO DEFINE THE 
FORMAT OF THE KST . NO STORAGE IS 
ASSIGNED RUT RATHER THE KST IS 
STORED IN A SEPARATELY OHTAINED 
area, (a segment SET ASIDE FOR IT)! 

$ABS 0 

0000 KST ARRAY [MAX_N0_KST_ENTR1ES KST_RECJ 
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GLOBAL 

SSECTION m GLB PP.OC 



0000 



H£‘AD PROCEDURE 

READS SPECIFIED fiVENTCOUNT 
^ AND RETURNS IT'S VALUE TO - 
THE CALLER 

sic J^s;: :(t V Jse V »i« 5? sjt 5? 5? 5!S W5i« 5? >»: 5(t ^ W ap 5? s? 



PARAMETERS: - 

Rl; SEGMENT # 

’i' R2; INSTANCE - 

n* V ^ 5^ »,S 5,5 #iC j;; SJS 5^5 



’i' RETURNS: =*« 

R0: SUCCESS CODE 
RR4: fiVENTCOUNT - 



ai<a?>?3(C3?3gc:ic37V;ic:^:(e>?3jS99p;gc;ic:(CJi(:((:;t>iC}? 3^>iC3^ais I 



ENTR"^ 

! SAVE INSTANCE ! 
0000 93FH PUSH 0R15, R2 



0002 2102 
0004 0001 

000b 5F00 
0008 0000' 



000A 0B00 
000C 0002 

000E 5E0E 
0010 001C' 

0012 97F2 
0014 5F00 
0016 0000’!' 



0018 5E08 
001A 001E' 
001C 97F2 

001E 9E08 
0020 



! "read" ACCESS REQUIRED ! 

LD R2, #READ_ACCESS 

! GET SEG HANDLE & VERIFY ACCESS ! 

CALL CONV£RT_AND_VERIFT !R1:SEG # 

R2:RE0. ACCESS 
RETURNS : 
R0:SUCCESS CODE 
Rl .-HANDLE PTR ! 

CP R0, #SUCCEEDED 

IF EQ lACCESS PERMITTED! 

THEN [READ EVENTCOUNT! 

IRESTORE INSTANCE! 

POP R2, PR15 

CALI MM_READ_EVENTCOUNT !R1:HPTP. 

R2: INSTANCE 
RETURNS : 
R0:SUCCESS CODE 
RR4:EVENTC0UNT ! 

ELSE !REST0RE SP! 

POP R2, OR 15 
FI 
RET 

END READ 
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202e TICKET PRCCEBURS 

'- RETURNS CURRENT VALUE OF - 

’^‘ TICKET TO CALLER AND INCRE- =>« 
^^ENTS SEOUENCER FOR NEXT - 

- TICKET OPERATION 

age V ^ ^ ^ ^ 3 gc age 3 ^ age a;c ^ :gc :gc 2 ^ :;c 3 ;c ^ :;c s;; age :;c : 9 c 9 ^ 39 c age 

PARAMETERS; 

Ri: SEGMENT # 

a^a^ aje ageage agcageageagcagcagcagesjeaicage age age a^ age age age age age age age age age age age age age 

RETURNS: 

- R0; SUCCESS CODE - 

RR4: TICKET VALUE 

:|c9;c9;c3;0e:9ic3p3ic9^9;i9;caic^sic3ic3ic3i(;:ic9icjic9:{:ai:9;c};c9^3;:9;«:p^;t: I 



0020 2102 
0022 0000 
0024 5F00 
002b 0000' 



0026 0R00 
002A 0002 

002c 5E0E 
002E 0038' 
0030 5F00 
0032 0000=^ 



0034 2100 
0036 0002 

0038 9E08 
003A 



ENTRI 

! GET SEG HANDLE & VERIFI ACCESS ! 

! "write" ACCESS REQUIRED ! 

LD R2, #WRITE_ACCESS 

CALL CONVERT_AND_VERIFY !R1:SEG # 

R2:ACCESS REQ 
RETURNS : 
R0:SUCCESS COD 
Rl .-HANDLE PTR! 

CP R0, ^SUCCEEDED 

IF EO lACCESS PERMITTED! 

THEN ! GET TICKET ! 



CALL MM_?ICKET IRlrEANDLE PTR 

RETURNS : 
RR4:TICKET! 

! RSTORE SUCCESS CODE ! 

LD R0, ^SUCCEEDED 



FI 

RET 

END TICKET 



003A 



await PROCJCDURE 



^ CURRENT EVENTCOUNT VALUE IS 
^ COMPARED TO USER SPECIEIED - 
^ VALUE. IF USER VALUE IS 



GREATER THAN CURRENT EVENT- 

- COUNT VALUE THEN PROCESS IS - 
^ ’’blocked" UNTIL THE DESIRED 

- EVENT OCCURS . 



ifi ^ •{* 3i|£3i* 3yC 9^ 9^ 9^ ^C9|C 9J* 9^ 9^ 9}C 9^ 9|^ 9l(* 9^ 9||S 9|* 9^9^ Tfi 9,% 



=" PARAMETERS: ^ 

R1 : SEGMENT # ^ 

- R2: INSTANCE (EVENT #) - 

=5' RR4; SPECIFIED VALUE 

^ 3ic ^ 3)c 3JC :(c 3^ 9^ 7 >r ? 7 7 ^ 39 c V 



- RETURNS: 

Re: SUCCESS CODE ^ 

Xf7fVW3fWV>f3f7)i3f3)tj;^3fW:3)t3f3fVWVWWW J 



003A 91F4 

ee3C 93F2 

003E 2102 
0040 0001 

0042 5F00 
0044 0000' 



0046 0B00 
0048 0002 

004A 5E0E 
004C 005A' 

004E 97F2 

0050 95F4 
0052 5F00 
0054 0000*^ 



ENTRY 

! SAVE DESIRED EVENTCOUNT VALUE ! 

PUSHL 0R15, RR4 
! SAVE INSTANCE ! 

PUSH 0R15, R2 
! ’’read’’ access REOUIRED ! 

LD R2, #READ_ACCESS 

! GET SSG HANDLE S. VERIFY ACCESS ! 

Call convert_and_verift !ri:seg # 

R2:ACCESS REQ 
RETURNS: 
R0:SUCCESS CODE 
Rl:HANDLE PTR! 

CP R0, #SUCCEEDED 

IF EO ! ACCESS PERMITTED ! 

TEEN ! AWAIT EVENT OCCURRENCE ! 

! RESTORE INSTANCE ! 

POP R2, PR15 

! RESTORE SPECIFIED VALUE ! 

POPL RR4, OR Id 

CALL TC_AWAIT !R1: HANDLE PTR 

R2:INSTANCE 
RR4: VALUE 
RETURNS: 

R0:SUCCESS CODE! 
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0056 

0058 


5E08 
005E ' 


ELSE ! RESTORE STACK 


005A 


95F4 


POPI ?.R4, 0R15 


005C 


97E2 


POP R2, GR15 

FI 


005E 

0060 


9E08 


RET 

END AWAIT 
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0060 AD^ANCi; PP.OCEDURE 

f i|5 V V V V ^ V V ^ ^ ^ V V W ^ ••• ^ ^ V 

V SIGNALS THE OCCURRENCE OF 

- SOME EVENT. EVENTCOUNT IS 

- INCREMENTED AND THE TRAFFIC 

- CONTROLLER IS INVOKED TO 

AWAKEN ANT PROCESS AWAITING ^ 

- THE OCCURRENCE. - 

^ iic ?;c ^ 9;c ;ge ^ 9;c 9iC s;t :ic 9;c ^ s;s ^ 9^ 3jS ?;c ^ 3^ )ic :ijC 

PARAMETERS: =** 

- Rl: SEGMENT # 

R2: INSTANCE (EVENT P) ^ 

RETURNS: - 

R0: SUCCESS CODE 



ENTRY 

! SAVE INSTANCE ! 
0060 93F2 PUSH 0R15, R2 



! GET SEG HANDLE & VERIFY ACCESS ! 

! "write" ACCESS REQUIRED ! 

0062 2102 LD R2, #WR I TE_AC CESS 
0064 0000 

0066 SF00 CALL CONVERT AND_VERIFY !R1:SEG # 

0068 0000' 

R2;ACCESS REC 
RETURNS : 
R0:SUCCESS CODE 
Rl: HANDLE PTR! 



006A 

006C 


0B00 

0002 


CP R0, ^SUCCEEDED 

IF EO ! ACCESS PERMITTED ! 


006E 

0070 


5E0E 

007C' 


THEN ! advanced EVENTCOUNT ! 
! RESTORE INSTANCE ! 


0072 


97F2 


POP R2, ORlb 


0074 


5F00 


CALL TC_ADVANCE !R1:HANDLE PTR 


0076 


0000’i' 


R2: INSTANCE 
RETURNS : 

R0:SUCCESS CODE! 


0078 

007A 


5E08 

007B' 


ELSE IRESTORE STACK! 


007C 


97F2 


POP R2, 0R15 

FI 


007E 

0080 


9E08 


RET 

END ADVANCE 
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INTERNAL 

SSECTION EM INT PROC 



fdfiHZ CCNVERT_ANr_7SRIPY PROCEEURE 

f ^ V 3.C r,s V V ^ V -fi w ^ W ^ V ^ 7,s V V 

’!' CONVERTS SEGMENT NUMRER TO 5ST INEEX^ 
’i' AND EXTRACTS SEGMENT'S HANDLE PROM ’i' 
KST. IP SUCCESSPUL, THEN ACCESS - 

CLASS OP SUBJECT IS CHECKED AGAINST 
’i' ACCESS CLASS OP OBJECT TO INSURE 

- that access is permitted. - 

j;c 3ic :gc sjc ;gc ap ;gc 3ic 3ic ;gc ;gc 9^ :«( 3iC ;;c Jic :gc Sic 3ic 9 9ic 3iC ;gc >;( 9^ 9^ 9^ 3ic 3ic 3iC :gc ;gc 7 ;gc 

PARAMETERS: 

=•' Rl: SEGMENT NUMBER 
^ R2: ACCESS REQUESTED 

2;e ^ djc ^ ?}( 3^ 3JC 9(c>^ ^ s;c ?je ^ ?ie 9;s 9iC3ic ?;c 9? ?ic 9QC 3^ 3}c sgc 9^ sq: 9}c 9ic 3^ 9^ sjc 

- RETURNS: ^ 

’i' R0: SUCCESS CODE 

Rl : HANDLE POINTER 



0000 93P2 

0002 5F00 
0004 0062' 



0006 0B00 
0008 0002 

000A 5E0E 
000C 005E' 

000E 91P4 

0010 5P00 
0012 0000 ^ 



0014 95F0 
0016 1414 
0018 97F1 
001A 93F0 



ENTRY 

! SAVE requested ACCESS ! 

PUSH (?R15, R2 
! GET SEGMENT HANDLE ! 

CALL GET_HANDLE !R1:SEG # 

RETURNS : 

R0:SUCCESS CODE 
R4:HANDLE PTR 
R5: CLASS PTR! 

CP R0, #SUCCEEDED 

IF EO ! SEGMENT IS KNOWN ! 

THEN ! VERIFY ACCESS ! 

! SAVE handle & CLASS PTR ! 

PUSHL 0R15, RR4 
! GET SUBJECT'S SAC ! 

CALL PROCESS_CLASS ! RETURNS: 

RR2:PR0C CLASS! 

! RETRIEVE SEG CLASS POINTER ! 

POPL RR0, 0R15 
! GET SEGMENT'S CLASS ! 

LDL RR4, ORl 

! RETRIEVE REQUESTED ACCESS ! 

POP PI, 0R15 
! SAVE HANDLE POINTER ! 

PUSH (?R15, R0 
! CHECK ACCESS CLEARANCE ! 



Ill 



001C 

001E 

0020 

0022 

0024 

0026 



0028 

002A 

002C 

002E 

0030 

0032 

0034 

0036 

0038 

003A 

003C 

003E 

0040 

0042 



0044 

0046 

0048 

004A 

004C 

004E 

0050 

0052 

0054 

0056 



0058 

005A 

005C 

005E 

0060 

0062 



0B01 CP Rl, #WRITE_ACCESS 

0000 

IF EO ! WRITE ACCESS REQUESTED ! 

5E0E THEN 

0040 ' 

5F00 CALL CLASS_EO !RR2:PR0CESS CLASS 

0000V 

RR4:SEGMENT CLASS 
RETURNS : 

Rl: CONDITION CODE! 

0B01 CP Rl, #FALSE 

0000 

IF EO lACCESS NOT PERMITTED! 

5E0E THEN 

0038 ' 

2100 LD R0, #ACCESS_CLASS_NOT EO 

0021 

5E08 ELSE !ACCESS PERMITTED! 

003C ' 

2100 LD R0, ^^SUCCEEDED 

0002 

FI 

5E08 ELSE ! READ ACCESS REQUESTED ! 

0058' 

5F00 CALL CLASS GE !RR2 .‘PROCESS CLASS 

0000 =*' 

RR4:SEGMENT CLASS 
RETURNS : 

RltCONDlTlON CODE! 



0E01 


CP 


Rl, #EALSE 


0000 


IF EC 


lACCESS NOT PERMITTED! 


5E0E 


THEN 




0054' 

2100 


LD 


R0, #ACCESS_CLASS_NOT_CE 


0029 

5E08 


ELSE 


lACCESS PERMITTED! 


0058 ' 
2100 


LD 


R0, #SUCCEEDED 


0002 


FI 

FI 

! RETRIEVE HANDLE POINTER ! 


97F1 


POP Rl 


, 0R15 



5E08 ELSE 

0060' 

! RESTORE STAGE ! 
97F2 POP R2, 0R15 

FI 

9E08 RET 

END CONVERT AND VERIFY 
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0feJ62 

0064 

0066 
0068 
006A 
006 C 

006 E 

0070 

0072 

0074 

0076 

0078 

007A 

007C 

007E 

0080 

0082 

0084 



0086 

0088 

008A 
008 C 

008E 



GET HANDLE PROCEDURE 

CONVERTS SEGMENT NUMBER TO 
EST INDEX AND DETERMINES IF 
’1' SEGMENT IS KNOWN. IF KNOWN >«= 
POINTER TO SEGMENT HANDLE ^ 
AND POINTER TO SEGMENT CLASS’^ 
’i' ARE RETURNED. 

:;c V ^ ^ 9SC ^ s? M ;^c a;fi W ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 

’i' PARAMETERS: 

Rl: SEGMENT NUMBER 



JJt 


RETURNS: 


35c 




R0 : 


SUCCESS CODE 


3 ? 




R4: 


HANDLE POINTER 


V 




R5: 


CLASS POINTER 








ENTRT 

! CONVERT SEGMENT # TO KST INDEX # ! 

0301 SUB Rl, #NR_0F_KSEGS 

000A 

! VERIFI KST INDEX ! 

2100 LD R0, #SUCCEEDED 

0002 

0B01 CP Rl, #0 

0000 

IF LE '.INDEX NEGATIVE! 

5E0A THEN 

007A' 

2100 LD R0, #SEGMENT NOT KNOWN 

001C 

5E08 ELSE ! INDEX POSITIVE! 

0086' 

0B01 CP Rl, #MAX_NO KST_ENTP.IES 

0036 

IF GT ! EXCEEDS MAXIMUM INDEX! 

5E02 THEN ! INVALID INDEX! 

0086' 

2100 LD R0, #SEGMENT NOT_KNOWN 

001C 

FI 

FI 

0B00 CP R0, #SUCCEEDED 
0002 

IF EO ! INDEX VALID! 

5E0E THEN 

00BE' 

! SAVE KST INDEX ! 

93F1 PUSH 0R15, Rl 

! GET KST ADDRESS ! 
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0090 


2101 


LD 


Rl, #KST_SEG_NO 


0092 


0002 






0094 


5E00 


CALL 


ITC_G£T_SEG_PTR ! fil :KST_SEG_NO 


0096 


0000V 




RETURNS : 
R0:KST ADER! 






r HETPIEVE KST INDEX # ! 


0098 


97F3 


POP 


R3, 0R15 






! CONVERT KST INDEX # TO KST OEFSET 


009A 


1902 


MULT 


RR2, #SIZEOF KST_REC 


009C 


0010 










! COMPUTE KST ENTRY ADDRESS ! 


009E 


8103 


ADD 


R3, R0 






! SEE 


IF SEGMENT IS KNOWN ! 


00A0 


4D31 


CP 


KST.M_SEG_N0(R3). #NOT_KNOWN 


00A2 


000E 






00A4 


00FF 


IF EO 


ISEGMENT NOT KNOWN! 


00A6 


5E0E 


then 




00A8 


00B2' 






00AA 


2100 


LD 


R0, #SEGMENT_NOT_KNOWN 


00AC 


001C 






00AE 


5E08 


ELSE 


fSEGMENT KNOWN! 


00E0 


00BE' 






00B2 


2100 


LD 


R0, #SUCCEEDED 


00B4 


0002 










! GET HANDLE POINTER ! 


00B6 


7634 


LDA 


R4. KST.MM_HANDLE(R3) 


00B8 


0000 










I GET CLASS POINTER ! 


00BA 


7635 


LDA 


R5, KST.CLASS(R3) 


00BC 


000A 


FI 








FI 




00BE 


9E08 


RET 





00C0 END GET_HANDLE 

END EVENT MGR 
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APPENDIX B - TRAFFIC CONTROLLER LISTINGS 



Z8000ASM ^.02 
LOC OBJ CODE 



STMT SOURCE STATEMENT 



SLISTON $TTY 
TC MODULE 



CONSTANT 



t system PARAMETERS j 



NR PROC 


: = 4 


vp"nr 


:= 2 


nr"cpu 


:= 2 


NR KST 


:= 54 


S'^’STEM CONSTANTS 


RUNNING 


= 0 


READY 


= 1 


BLOCKED 


= 2 


IDLE PROC 


= :SDDDD 


NIL 


= i;ffff 


INVALID 


= %EEEE 


KERNEL STACK 


= 1 


USER STACK 




KST SEG 


= 2 


KST LIMIT 


= 1 


USER FCW 


= !«i80e 


vmiTE 


= 0 






(INDICATES LO'^^EST SYSTEM 
SECURITY CLASS ! 



S^STEM_LOW 

STK_OFFSET 

REMOVED 

TRUE 

FALSE 

SUCCEEDED 



0 

%?¥ 

%K£CD 

1 

0 

2 



<J>YP2 

AP PTR 
VP'PTR 
ADDRESS 
H ARRAY 



WORD 
WORD 
WORD 
ARRAY L3 



WORDJ 
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AP TABLE RECORD 
[NEXT AP 
DBR ■ 

SAC 

PRI 

STATS 

AFPINITY 

VP_ID 

HANDLE 

INSTANCE 

VALUE 

FILi_2 

J 



AP_PTR 

WORD 

LONG 

INTEGER 

INTEGER 

WORD 

7P_PTR 

H ARRAi 

WORD 

LONG 

ARRAY [2 WORDJ 



RUN_ARRAT 
RDY_ARRAI 
AP DATA 
VP~DATA 
INR VP 
FIRST 

J 



ARRAY [VP NR AP_PTRJ 
ARRAY [NR"CPU AP_PTRJ 
ARRAY [NR_PROC AP_TABLIJ 
RECORD 

ARRAY [NR CPU WORDJ 
ARRAY [NR^CPU VP_PTRJ 



KST RSC RECORD 

[MM_EANDLE H.ARRAY 



SIZE 


WORD 




ACCESS 


BYTE 




IN CORE 


BYTE 




CLASS 


LONG 




M SEG NO 


SHORT 


INTEGER 


ENTRY NUM 

J 


SHORT, 


INTEGER 


EXTERNAL 






K LOCK 




PROCEDURE 


k“unlock 




PROCEDURE 


SET PREEMPT 




PROCEDURE 


SWAP VDBR 




PROCEDURE 


IDLE 




PROCEDURE 


RUNNING VP 




PROCEDURE 


CREATE TnT 


VEC 


PROCEDURE 


LIST INSERT 




PROCEDURE 


ALLOCATE MMU 


PROCEDURE 


MM ALLOCATE 




PROCEDURE 


UPDATE MMU 


IMAGE 


PROCEDURE 


CREATE STACK 


PROCEDURE 


MM ADVANCE 




PROCEDURE 


MM read EVENTCOUNT 


PROCEDURE 


G AST LOCK 




WORD 


PREEMPT RET 




LABEL 
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e4?0e 



00A0 

00A2 



0000 



0000 



0000 



$SSCTI0IM TC_DATA 
INTERNAL 

APT RECORD 

r LOCK 

RUNNING_LIST 
READY LIST 
£LOCKED_LIST 
FILL_;3 
7P 

FILL 

AP 

J 



WORD 

RUN_ARRAI 
RDY ARRAY 
AP_PTR 
LONG 
VP_DATA 
ARRAY [4 WORD] 
AP DATA 



! THESE VARIABLES ARE USED DURING TC 
INITIALIZATION TO SPECIFY AVAILABLE 
ENTRIES IN TEE APT, AND ARE INITIAL- 
IZED B"^ TC_INIT IN THIS I t^PLEMEN TAT ION 
NEXT_VP WORD 
APT ENTRY WORD 



SSECTION TC LOCAL 
$ABS 0 

!NOTE: USED AS OVERLAY ONLY! 



ARG_LIST 

[REG 

IC 



RECORD 

ARRAY [i;5 WORDJ 
WORD 



CPU_ID WORD 
SACl LONG 
PR II WORD 



USR_STK WORD 
KER_STK WORD 
KSTl LONG 

J 



$ABS 0 

!NOTE: USED AS STACK FRAME FOR 
STORAGE OF TEMPORARY VARIABLES 
FOR CREATE PROCESS.! 

CREATE “record 
[ARG_PTR WORD 

DBR NUM WORD 

LIMITS WORD 

SEG_ADDR ADDRESS 
N S_P WORD 

J 



sabs 0 

HANDLE_VAL RECORD 
[HIGH LONG 
LOW WORD 

] 
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0000 



0000 



!THE FOLLOWING DECLARATION IS UTILIZED 
AS A STACK FRAME FOR STORAGE OF 
TEMPORARY VA^^IABLES UTILIZED ST 
TC_AD7ANCE AND TC AWAIT.! 

$ASS 0 

TEMP RECORD 



[HANDLE PTR 


WORD 


EVENT NR 


WORD 


EVENT VAL 


LONG 


ID VP" 


WORD 


CPU NUM 


WORD 


HANDLE HIGH 


LONG 


HANDLE LOW 


WORD 



J 

SSECTION TC_KST_DCL 
!NOTE: KST DECLARATION IS USED HERE 
TO SUPPORT KST INITIALIZATION FOR 
THIS DEMONSTRATION ONLY. THIS 
DECLARATION AND INITIALIZATION 
SHOULD EXIST AT THE SEGMENT MANAGER 
LEVEL AND THUS SHOULD BE REMOVED 
UPON IMPLEMENTATION OF SYSTEM 
INITIALIZATION. ! 

$ABS 0 

KST ARRAY [NR_KST KST_RECJ 
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0000 



$SECTION TC INT FROG 

TC_GETW0RK ■ PROCEDURE 

f 5y^fr*SJC3i?3^5iS3iS5JSSJ5SiS55535tJjt5it5J535SSJ?JJS3|C3JCSJCJ^3JS3JC5JC5JC35C5jt 

PROVIDES GENERAL MANAGE- ’i' 
- MENT OE USER PROCESSES BY - 
EFFECTING PROCESS SCHEDU- 
^ LING ON VIRTUAL PROCESSORS’^ 



PARAMETERS: 



’i' Rl: CURRENT VP ID 
R3: LOGICAL CPU # 



’i' LOCAL variables: ^ 

R2: NEXT READY PROCESS 
’i’ R4: AP FTR - 

9;c3ic9ic^^3^^9^a;ca;c:;c3;c9^^^9^3ic:;c3^^a;c:9e^si<a;c9^;;c$^a;c I 



0000 6132 
0002 0006' 



0004 0E02 
0006 FFFF 
0008 5E0B 
000A 0010' 
000C 5E08 
000E 0026' 

0010 4D21 
0012 002A' 
0014 0001 
0016 5E0E 
0018 001E' 
001A 5E08 
001C 0026' 



001E 6124 
0020 0020 ' 
0022 A142 
0024 E8EF 
0026 0B02 
0028 FFFF 
002A 5E0E 
002C 003C' 

002E 4D15 
0030 0002' 
0032 DDDD 



ENTR'»’ 

I FIND FIRST READY PROCESS ! 

LD R2, APT.READY_LIST(R31 

GET_REaDT_AP: 

DO IWHILE NOT (END OF LIST OR READY)! 
CP R2, #NIL 

IF EO !NO READY PROCESS! THEN 
EXIT FROM GET_READY_AP 
FI 

C? APT.AP.STATE(R2) , #READY 



IF EO ! PROCESS READY! THEN 
EXIT FROM GET_READY_AP 
FI 

! GET NEXT AP FROM LIST ! 

LD R4, APT.AP.NEXT_AP(R^!) 

LD R2 , R4 

OD 

CP R2,i#NIL 

IF SO ! IF NO PROCESSES READY ! TEEN 

! LOAD IDLE PROCESS ! 

LD APT.RUNNING_LIST(R1 ) , #IDLE_PROC 
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0034 

0036 


*1700 

00005 ? 


CALL 


IDLE 


0038 

003A 


5E08 

0052' 


ELSE 

! load EIRST READY AP ! 


003C 

003E 


6E12 

0002' 


LD 


APT.RUNNING_LIST(R1 ) , R2 


0040 

0042 

0044 


4D25 

002A' 

0000 


LD 


APT.AP. STATE(R2) , #RUNNING 


0046 

0048 


6E21 

002B' 


LD 


APT.AP.VP_ID(R2) , R1 


004A 

004C 


6121 

0022' 


LD 


Rl, APT.AP.DBR(R2 ) 


004E 

0050 


5F00 

0000>* 


CALL 

FI 


SWAP_7DBR !(R1:DBR)! 


0052 


9E08 


RET 




0054 




END TC 


GETWORK 
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ees4 



e0tj4 

0056 

0058 

005A 

005C 

005E 



0060 

0062 



0064 

0066 

0068 

006A 

006C 

006E 

0070 



0072 

0074 



0076 

0078 

007A 

007C 



VIETUAL_PREEMPT HANDLER PROCEDURE 

- LOADS FIRST READY AP - 
IN RESPONSE TO PREEMPT =<' 
INTERRUPT ==* 



ENTRY 

CALL WAIT_L0CK (APT''. LOCK) 

!=*'^ RETURNS WEEN PROCESS HAS LOCKED AFT ! 



7604 

0000' 


LDA 


R4, APT. LOCK 


5F00 


CALL 


K_LOCK 


0000’^ 








! GET 


RUNNING VP ID ! 


5F00 


CALL 


RUNNING_VP IRETURNS: 


0000>^ 







R1 :VF_ID 
R3:CFU a\ 



! GET AP ! 

6112 LD R2, APT.RUNNING_LIST(R1) 

0002 ' 

! IF NOT AN IDLE PROCESS, SET IT TO READY ! 
0E02 CP R2, #IDLE_PROC 

DDDD 

5E06 IF NE ! NOT IDLE ! THEN 
0072' 

4D25 ID APT.AP.STATE(R2) , i^READT 

002A' 

0001 

FI 

! LOAD FIRST READY PROCESS ! 

5F00 CALL TC_GSTWORK !R1:VP_ID 

0000 ' 

R3:CPU #! 

!NOTE: THIS IS THE INITIAL POINT OF 
EXECUTION FOP USER PROCESSES.! 
VIRT_PREEMPT_RETURN: 

!="=^ CALL UNLOCK (APT''.L0CK) 

RETURNS WHEN PROCESS HAS UNLOCKED APT 
AND ADVANCED ON THIS EVENT 
7604 LDA R4, APT. LOCK 

0000 ' 

5F00 CALL K_UNLOCK 

0000V 
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! PERfORM A VlRTaAL INTERRUPT RETURN 
!NOTE: THIS JUMP EPFECTS A VIRTUAL 
IRET INSTRUCTION.! 

0O7E 5E08 JP PREEMPT_RET 
0080 0000- 

0082 END VIRTUAL PREEMPT HANDLER 
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GLOBAL 

SSECTION TC_GLB_PROC 

0000 TC_INIT PROCEDURE 

^ INITIALIZES APT HEADER 
’i' AND VIRTUAL I NT VECTOR ’i' 

9ic 3 ;; V 9iC ^ ^ 3^ s? 3 ;: ^ V ^ s;^ 3ic ^ V V 

PARAMETERS: 

Rl: CPU_ID 
- R2: NR_VP 

3f3f3f3f7f7}C3fSf7;i3f3f3)t!f)f3f3f3f3f3f>)i>}l3f3f3f3f3f3fif3f I 



ENTRY 

! NOTE: THE NEXT FOUR VALUES ARE 
ONLY TO BE INITIALIZED ONCE. ! 



0000 

0002 

0004 


4D05 

00A0' 

0000 


LD 


NEXT_VP, #0 


0006 

0008 

000A 


4D05 

00A2' 

0000 


LD 


APT_ENTRY, 


000 c 

000E 

0010 


4D05 

000A' 

FFFF 


LD 


apt.blocked_list 


0012 

0014 


4D08 

0000' 


CLR 


APT. LOCK 



f :^:(c9ic:tc9^9^3r3r:gc3gc:gc3ic;gc:;c3^:jc>^:^:p9^3)c:;::?^ 

NOTE: THE FOILOWING CODE IS INCLUDED 
ONLY FOR SIMULATION OF A MULTIPROCESSOR 
ENVIRONMENT. THIS IS TO INSURE THAT THE 
READY LIST(S) AND VP DATA OF THE SIMULATED 
C?U(S) APE PROPERLY INITIALIZED. IN AN 
ACTUAL MULTIPROCESSOR ENVIRONMENT, THIS 
BLOCK OF CODE SHOULD BE REMOVED. 



0016 


2104 


LD R4, ttid 


0018 


0000 


DO 


001A 


0B04 


CP R4, #NR_CPU’^2 


001 c 


0004 


IF EO !ALL LISTS INITIALIZED! 


001E 


5E0E 


THEN EXIT 


0020 


0026' 




0022 


5E08 




0024 


0036' 


FI 
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! INITIALIZE READ! LISTi AS EMPTY ! 



0«26 


4D45 




LD APT.READY_LIST(R4) , #NIL 


0028 


0006' 






002A 


FFFF 




! INITIALLY MARK ALL LOGICAL CPU'S 








AS HAVING 1 VP. THIS IS NECESSARY 
TO INSURE TC ADVANCE WILL FUNCTION 
PROPERLY, AS "IT EXPECTS EVERY CPU 
TO HAVE AT LEAST 1 VP . ! 


002C 


4D45 




LD APT.VP.NR_VP(R4) , #1 


002E 


0010' 






0030 


0001 






0032 


A941 




INC R4, #2 


0034 


E8F2 




OD 






! END MULTIPROCESSOR SIMULATION CODE. 








0036 


6F12 


LD 


APT.VP.NR_VP(R1) , R2 


0038 


0010' 






003A 


6103 


LD 


R3, NEXT_VP 


003C 


00A0' 






003E 


6F13 


LD 


APT.VP.FIRST(R1 ) , R3 


0040 


0014' 










! RECOMPUTE NEXT VP VALUE FOR TC 






INITIALIZATION OF NEXT LOGICAL 






CPU 


. ! 


0042 


A 125 


LD 


R5, R2 


0044 


1904 


MULT 


RR4, #2 


0046 


0002 






0048 


8153 


ADD 


R3, R5 


004A 


6F03 


LD 


NEXT_VP, E3 


004C 


00A0' 










! INITIALIZE RUNNING LIST f 


004E 


6113 


LD 


R3, APT.VP.?IRST(P1 ) 


0050 


0014' 


DO 




0052 


0E02 


CP 


R2, «0 


0054 


0000 






0056 


5E0E 


IF 


EO then exit FI 


0058 


005E' 






005A 


5E08 






005C 


006A' 






005E 


4B35 


LD 


APT.RUNNING_LIST(R3^ . #IDO_PRCC 


0060 


0002' 






0062 


DDDD 






0064 


A931 


INC 


R3, <»2 


0066 


AB20 


DEC 


R2, #1 


0068 


E8F4 


OD 




006A 


4D15 


LD 


APT.READY_LIST(R1) , #NIL 


006C 


0006' 






006E 


FFFF 
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0070 

0072 

0074 

0076 

0078 

007A 



007C 

007E 



2101 

0000 


LD 


R1 , #0 






! ENTRY ADDRESS ! 




7602 


LDA 


R2, VIRTUAL PREE.VPT HANDLER 


0054' 








5F00 


CALL 


CREATE_INT_VSC 




0000V 




IRliVIRTUAL INTERRUPT 


a 






R2: INTERRUPT HANDLER 


ADDRESS 


9E08 


RET 

END TC 


_INIT 
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ee?E 



CREATE PROCESS PROCEDURE 



- CREATES USER PROCESS '••' 
=!' DATABASES AND APT 
’i' ENTRIES 



S^S S(S SJ6 9^ 9JC 9JC SJS 3|*9^ 9^ 5JS 3? 5? 5jS 9^ JJS 



PARAMETERS : 

’i' Rl4: argument PTR 

37VSr wx: j 



ENTRY 

!N0TE; THIS PROCEDURE IS A STUB TO ALLOW 
PROCESS INITIALIZATION FOR THIS 
DE^-'ONSTRATION . ! 

! ESTABLISH STACK PRAMS FOR LOCAL 
VARIABLES, ! 



00?E 


030F 


SUB 


R15, #SIZEOF CREATE 


0080 


000A 










! STORE INPUT ARGUMENT POINTER ! 


0082 


6FFE 


LD 


CREATE. ARG^PTR( R15) , R14 


0084 


0000 










! LOCK APT ! 


0086 


7604 


LDA 


R4, APT. LOCK 


0088 


0000 ' 






008A 


5F00 


CALL 


K_LOCK 


008C 


oeoe*!* 










! RETURNS WHEN APT IS LOCKED ! 

! CREATE MMU ENTRY FOR PROCESS ! 


008E 


5F00 


CALL 


ALLOCATE_MMU ’RETURNS: 


0090 


0000V 




R0: DBR ff! 






! GET 


NEXT AVAILABLE ENTRY IN APT 


0092 


6101 


LD 


Rl, APT ENTRY 


0094 


00A2' 










! COMPUTE APT OFFSET ! 


0096 


2102 


LD 


R2, #SIZEOF AP.TABLE 


0098 


0020 






009A 


8112 


ADD 


R2, Rl 






! SAVE NEXT AVAILABLE APT ENTRY ! 


009C 


6F02 


LD 


APT_ENTRY, R2 


009E 


00A2' 










! create apt entry for process ! 


00A0 


4D15 


LD 


APT.AP.NEXT_AP( Rl ) , #NIL 


00A2 


0020' 






00A4 


FFFF 






00A6 


6F10 


LD 


APT.AP.DBR(R1 ) , R0 


00A8 


0022' 


! GET 


PROCESS CLASS ! 


00AA 


54E2 


LDL 


RR2, ARG_LIST.SAC1(R14) 


00AC 


001E 






00AE 


5D12 


LDL 


APT.AP.SAC(R1 ) , RR2 
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00B0 0fe?24 







! GST 


PROCESS PRIORITY ! 


00B2 


61E2 


ID 


R2, ARG_LIST.PRI1(R14) 


00B4 


0022 






00B6 


6F12 


LD 


APT.AP.PRI(Rl) , R2 


00B8 


0028' 


! GET 


LOGICAL CPU # ! 


00BA 


61E2 


LD 


R2, APG_LIST.CPU_ID(R14) 


00EC 


001C 






00BE 


6F12 


LD 


APT.AP.AFFINITY(Rl), R2 


00C0 


002C' 










ITHREAD IN LIST AND MAKE READY! 


00C2 


7623 


LDA 


R3, APT.READY_LIST(P-2) 


00C4 


0006' 






00C6 


7604 


LDA 


R4, APT.AP.NEXT_AP 


00C8 


0020' 






00CA 


7605 


LDA 


R5, APT.AP.PRI 


00CC 


0028' 






00CE 


7606 


LDA 


R6, APT. AP. STATE 


00D0 


002A' 






00D2 


2107 


LD 


R7, #READY 


00D4 


0001 






00D6 


AD 21 


EX 


Rl, R2 






! SAVE DER # ! 


00 D8 


6FF0 


LD 


create. D3R_NUM(R15) , R0 


00DA 


0002 






00DC 


5F00 


CALL 


LIST_INSERT 


00DE 


0000>? 












IR2: OBJ ID 








R3: LIST HEAD PTR 
R4: NEXT OBJ PTR 
R5: PRIORITY PTR 
R6: STATE PTR 
R7: STATE! 



! UNLOCK APT ! 



00E0 


7604 


LDA 


R4, APT. LOCK 


00E2 


0000' 






00E4 


5F00 


CALL 


K_UNLOCK 


00E6 


0000’!' 










'CREATE USER STACK! 






! RESTORE ARGUMENT POINTER ! 


00E8 


61FE 


LD 


R14, CREATE. ARG_PTR fR15) 


00EA 


0000 






00EC 


61E3 


LD 


R3, ARG_LIST.USR_STK(R14) 


00EE 


0024 










! SAVE LIMITS ! 


00F0 


6FF3 


LD 


CREATE. LIMITS(R15) , R3 


00F2 


0004 







127 



N'; 






00F4 


5F00 


CALL 


MM_ALLOCATE ! R3 : a OF BLOCKS 


00F6 


0000J.S 












RETURNS : 








R2: START ADDR! 






ICOMPUTE & SA?E NSP! 


00F8 


A128 


LD 


R8, R2 






! ESTABLISH INITIAL SP VAIUE 






FOR 


USER STACK. ! 


00FA 


0108 


ADD 


R8, #STK_OFFSET 


00FC 


00FF 






00FE 


6FF8 


LD 


create. N_S_P(R15) , RS 


0100 


0008 










! RESTORE LIMITS ! 


0102 


61F4 


LD 


R4, CREATE. LIMITS (R15) 


0104 


0004 






0106 


AB40 


DEC 


R4 ! SEG LIMITS ! 






! RESTORE DBR ! 


0108 


61F0 


LD 


R0, create .DBR_NUM(R15) 


010A 


0002 






010C 


2101 


LD 


Rl, #user_stack 


010E 


0003 






0110 


2103 


LD 


R3, #WR1TE ! ATTRIBUTE! 


0112 


0000 






0114 


5F00 


CALL 


UPDATE_MMU_IMAGE 


0116 


0000=«‘ 







IH0; DBR n 
Hi: SEGMENT 
R2: SEG ADDRESS 
R3: SEG ATTRIBUTES 
R4: SEG LIMITS ! 
'CREATE KERNEL STACK! 

! RESTORE ARGUMENT POINTER ! 



0118 

011A 


61FE 

0000 


LD 


R14., CREATE. ARG_ 


PTR(Rlb) 


011C 

011E 


61E3 

0026 


LD 


R3, ARG_LIST.KER 


_STK(R14) 


0120 

0122 


5F00 

0000=1' 


call 


MM_ALLOCATS !R3: 


n OF BLOCKS 



RETURNS 

R2: START ADER! 

IMAKE MMU ENTRY! 

! RESTORE DBR n ! 



0124 

0126 


61F0 

0002 


LD 


R0, 


CREATE. DBR_NUM(R15) 


0128 

012A 


2101 

0001 


LD 


Rl, 


#KERNEL_STACK 


012C 


A 134 


LD 


R4, 


R3 


012E 


AB40 


DEC 


R4 




0130 

0132 


2103 

0000 


LD 


R3, 


#¥RITE 






! SAVE START ADDRESS ! 



12b 



0134 


6FF2 


LD 


CREATE.SEG_ADDR(R15) , R2 


0136 


0006 






0138 


5F00 


CALL 


UPDATE_MMU_IMAGE 


013A 


0000*^® 




!R0: DBR a 



£1; SEGMENT # 

R2: SEG ADDRESS 
R3: SEG ATTRIBUTES 
R4: SEG LIMITS! 
lESTABLISH ARGUMENTS! 

! RESTORE ARGUMENT POINTER ! 



013C 


61FE 


LD 


R14, CREATE .ARG_PTR(R15) 


013E 


0000 










! RESTORE STACK ADDRESS ! 


0140 


61F1 


LD 


Rl, create. SEG_ADDR(R l 5) 


0142 


0006 






0144 


2103 


LD 


R3, #USER_FCW 


0146 


1800 






0148 


61 E4 


LD 


R4, ARG_IIST. IC (R14 ) 


014A 


001A 










! RESTORE INITIAL NSP ! 


014C 


61F5 


LD 


R5, CREATE. N_S_P(R15) 


014E 


0008 






0150 


7606 


LDA 


R6, VIRT_PREEMPT_RETURN 


0152 


0076' 






0154 


030F 


SUB 


R15, P8 


0156 


0008 






0158 


1CF9 


LDM 


GR15, R3, #4 


015A 


0303 










! LOAD ARGUMENT POINTER FOR 






CREATE STACK CALL ! 


015C 


A1F0 


LD 


R0, R15 


015E 


93F1 


PUSH 


0R15, Rl 


0160 


AlSl 


LD 


Rl, R14 






! LOAD INITIAL REGISTER VALUES 






BE 


PASSED TO USER PROCESS AS 






INITIAL PARAMETERS. ! 


0162 


5C11 


LDM 


R2, ARG_LIST.REG(R1 U Pi 


0164 


020C 






0166 


0000 






0168 


97F1 


POP 


Rl, 0R15 


016A 


5F00 


CALL 


CREATE^STACK 


016C 


0000V 












!R0: ARGUMENT PTR 








Rl: TOP OF STACK 



R2-R14: INITIAL 
REG STATES! 



!NOTE: THE ABOVE INITIAL REG STATES 
REPRESENT THE INITIAL PARAMETERS 
(VIZ., REGISTER CONTENTS^ THAT A 
USER PROCESS WILL RECEIVE UPON 
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INITIAL EXECUTION. 



016E 

0170 


010F 

0008 


ADD R16, #8 lOVERLAY PARAMETERS ! 

! ALLOCATE KST ! 


0172 

0174 


2103 

0001 


LD 


R3, #KST_LIMLT 


0176 


5F00 


CALL 


MM ALLOCATE !R3:# OF BLOCKS 


0178 


0000’^ 


RETURNS 

R2: START ADD?.! 

! RESTORE DBR ! 


017A 

017C 


61F0 

0002 


LD 

! SAV 


R0, create. DBR_NUM(R15) 
S KST ADDRESS ! 


017E 

0180 


6FF2 

0006 


LD 

!MAKE 


CREATE. SEG_ADDR(H15K R2 
MMU ENTRY FOR KST SEG! 


0182 

0184 


2101 

0002 


LD 


Rl, #KST_SSG 


0186 

0188 


2103 

0000 


LD 


R3, #WRITE IATTRIBUTE! 


018A 

018C 


2104 

0000 


LD 


R4, #KST_LIMIT-1 


018E 

0190 


5F00 

0000’S' 


CALL 


UPDATE_MMU_IMAGE 



0192 61F2 
0194 0006 

0196 5F00 
0198 01A0' 



019A 010E 
019C 000A 
019E 9E08 
01A0 



!R0: DBR u 
Rl: SEGMENT # 

R2: SEG ADDRESS 
R3: SEG ATTRIBUTES 
R4: SEG LIMITS ! 

! RESTORE KST ADDRESS ! 

LD R2. CREATE. SEG_ADDR(R15) 

! CREATE INITIAL KST STUB ! 
CALL CREATE_KST !R2:KST ADDP ! 

! REMOVE temporary VARIABLE 
STACK FRAME. ! 

ADD R15, #SI2EOF CREATE 

RET 

END CREATE PROCESS 
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01A0 



01A0 

01A2 

01A4 

01A6 

01A8 

01AA 

01AC 

eiAE 

01E0 

01JB2 

01B4 

01B5 

01E8 

01BA 

01BC 

013E 



01C0 

01C2 

01C4 

01C5 

01C8 

01CA 

01CC 



CPBATE_KST PROCEDURE 

f 9^* 3|* 2|» 2^ 3QC ijl S^i S(C 2|C Sj* 

’i' CREATES KST STUB FOR 
^ PROCESS ^'ANAUEMENT 
- DEMO. INSERTS ROOT - 
^ ENTRY IN KST. NOT 
=«' INTENDED TO BE FINAL 
PRODUCT. - 

^ PARAMETERS: 

R2: KST ADDRESS - 

ENTRY 

'NOTE: THIS PROCEDURE IS A STUB USED 
FOR INITIALIZATION IN THIS IMPLEMENTATION 
ONLY. THE ACTUAL INITIALIZATION CODE 
FOR THE KST WILL RESIDE ^T THE SEGMENT 
MANAGER LEVEL ONCE I MPIEMENTAT ION OF 
SYSTEM INITIALIZATION IS EFFECTED. ' 

! CREATE ROOT ENTRY IN KST ' 



1406 


LDL 


RR6, #-l 'ROOT HANDLE 


FFFF 

FFFF 

5D26 


LDL 


KST.MM_HANDLE(R2) , RR6 


0000 


'SET 


ROOT ENTRY « IN G AST ! 


4D25 


LD 


KST.MM_HANDLE[2J YR2) , 


0004 

0000 


! SET 


ROOT CLASSIFICATION ! 


1406 


LDL 


RR6, «SYSTEM_LOW 


0000 






0000 

5D26 


LDL 


KST.CLASS(R2) , RR6 


000A 


!SST 


MENTOR SEG #! 


4C25 


LDB 


KST.M_SEG_N0(R2) , #0 


000E 






0000 


'INITIALIZE FREE KST ENTRIES 




FOR 


DEMO. NOT FULL KST' 


2101 


LD 


Rl, #10 


000A 

0E01 


DO 

CP 


Rl, #0 



0000 

5E0E IF EC THEN EXIT FI 

01D0' 

5E08 
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01CE 

01D0 


01DE' 

0102 


ADE 


R2, #SIZEOF KST_REC 


01E2 


0010 






01D4 


4C25 


IDE 


KST.M_SEG_NO(R2) , #tFF 


01D6 


000E 






01D8 

01DA 


EFEF 

AB10 


DEC 


R1 


01DC 


EHF3 


OD 




01DE 


9E08 


EET 




01E0 




END CR£ATE_5ST 
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0ii;0 



tc_advance procedure 

=!' E7ENTC0UNT IS ADVANCED BY 

- INVOCATION OF MM ADVANCE. 
PROCESSES THAT aRE AWAITING ^ 
THIS EVENT OCCURRENCE ARE ’i' 

- REMOVED FROM THE BLOCKED LIST- 
AND MADE READY. THE READY - 

’i' LISTS ARE THEN CHECKED TO 
’i* INSURE PROPER SHEDULINC- IS 
^ EFFECTED. IF NECESSARY VIR- 
=** TUAL PREEMPTS ARE SENT TO ALL*^ 

- THOSE VP'S BOUND TO LOWER - 
=5' PRIORITY PROCESSES. 

^ ^ : 9 c 3 ^ ;qc :ge 9 ^ sjc V 3 ?e 3 ^ ^ aje :ge ^ 9 ^ 99 c :ge ^ :ge 3,: 3gc 



- PARAMETERS: 

Rl: HANDLE POINTER 
=5* R2: INSTANCE (EVENT #) 



3;; w 2^ V ^ ^ ^ ^ ^ 3 r ^ 5;: s,c 






=!« RETURNS : 

^ R0: SUCCESS CODE ’i' 

3|» SJ* 3^3|C 3{* 3^ 3{« 3^ Sfi 3^ 3{* 3iCS^ 5j* 3^( 3|^ ifi 3||»3j« 3^ SJS Sj* Sfi 3,C #(£ f 



01E0 030F 
01E2 0012 

01E4: 6FF1 
01E6 0000 
01E8 6FF2 
eiEA 0002 

01EC 7504 
01EE 0000 ' 
01F0 5F00 
01F2 0000’i' 



01F4 5F00 
01F6 0000’i‘ 



01F8 0B00 
01FA 0002 
01FC 5E0E 
01FE 0372' 



ENTRY 

! ESTABLISH TEMPORARY VARIABLE 
STACK FRAME. ! 

SUB R15, #SIZE0F TEMP 

! SAVE INPUT ARGUMENTS ! 

LD TEMP.HANDLE_PTR(R15) , Rl 

LD TEMP.EVENT_NR(R15) , R2 

! LOCK APT ! 

LDA R4, APT. LOCK 

CALL K_LOCK 

! RETURNS WHEN APT IS LOCKED ! 

! ANNOUNCE EVENT OCCURRENCE BY 
INCREMENTING SVEnTCOUNT IN G AST 
CALL MM_ADVANCE !R1 -.HANDLE PTR 

R2: INSTANCE 
RETURNS : 
R0:SUCCESS CODE 
RR2;BVENTC0UNT! 
CP R0, #SUCCEEDED 

IF EO THEN 
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fcJ20fe) 

0202 

0204 

0206 

0208 

020A 

020C 

020E 

0210 

0212 

0214 

0216 

0218 

021A 



021C 

021E 

0220 

0222 



0224 

0226 

0228 

022A 

022C 

022E 



0230 

0232 



0234 

0236 

0238 

023A 

023C 

023E 

0240 

0242 

0244 



! SAVE EVENTCOUNT ! 

5DF2 LEL TEMP. EVENT VAL(R15), RR2 

0004 

! RESTORE INSTANCE ! 

61E0 LD R0, TEMP.EVENT_NR(Rlb) 

0002 

! RESTORE HANDLE POINTER ! 

61F1 LD Rl, temp. HANDLE_PTR (R ib) 

0000 



5414 

0000 

5DF4 

000C 

6114 

0004 

6FF4 

0010 



! SAVE HANDLE ! 

LDL RR4, HANDLE_VAL.EIGH(Rl ) 
LDL TSMP.HANDLE_flIGH(R15), RR4 
LD R4, HANDLE_VAL.LOW(Rl ) 

LD TEMP. HANDLE LOW(Rlb), R4 



! AWAKEN ALL PROCESSES AWAITING 
THIS EVENT OCCURRENCE ! 

! GET FIRST BLOCKED PROCESS ! 



6101 
000A ' 


ID 


Rl, 


APT.BLOCKED_LIST 


7606 

000A' 


LDA 


R6 , 


APT.BLOCKED_LIST 



WAKE_UP; 

DO 



! DETERMINE IF AT END OF BLOCKED LIST 
0B01 CP Rl, #NIL 

FFFF 

IF EC ! NO MORE BLOCKED PROCESSES ! 
5E0E TEEN EXIT FROM WAKE UP 

0230' 

5E08 

02B4' 



FI 

! SAVE NEXT ITEM IN LIST ! 
6117 LD R7, APT.AP.NEXT_AP(R1 ) 

0020 ' 



! DETERMINE IF PROCESS IS ASSOCIATED 
WITH CURRENT HANDLE ! 



54F4 


LDL 


RR4 


000C 

5014 


CPL 


RR4 


0030' 


IF EC 


!HIi 


5E0E 


TEEN 




02A2' 

61F4 


LD 


R4, 


0010 

4B14 


CP 


H4, 
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0246 0034 



IF Eg ! HANDLE'S MATCH ! 



0248 


5E0E 


THEN ! CHECK FOR INSTANCE MATCH ! 


024A 


029C' 






024C 


61F0 


LD R0 


, TEMP .EVSNT_NR(R15) 


024E 


0002 






0250 


4E10 


CP R0 


, APT.AP.INSTANCE(R1 ) 


0252 


0036 ' 










IF EC ! 


INSTANCE MATCHES ! 


0254 


5E0E 


THEN 'DETERMINE IF THIS IS THE 


0256 


0296' 










OCCURRENCE THE PROCESS 






WAITING FOR ! 


0258 


54F2 


LDL 


RR2, TEMP.EVENT_VAL(R15) 


025A 


0004 






025C 


5012 


CPL 


RR2, APT. AP. VALUE ( R1 ) 


025E 


0038' 










IF GE 


lAWAITED EVENT HAS OCCUHRED 


0260 


5E01 


TEEN 


! AWAKEN PROCESS ! 


0262 


0290' 










! REMOVE FROM BLOCKED LIST ! 


0264 


2F67 


LD 


0R6, R7 






! SAVE local variables ! 


0266 


91F6 


PUSHL 0R15, RR6 






!SET 


LIST THREADING ARGUMENTS! 


0268 


6112 


LD 


R2, APT.AP.AFFINITY(RI) 


026A 


002C ' 






026C 


7623 


LDA 


R3, APT.READY_LIST(R2) 


026E 


0006' 






0270 


7604 


LDA 


R4, APT.AP.NEXT_AP 


0272 


0020' 






0274 


7605 


LDA 


P5, APT.AP.PRI 


0276 


0028' 






0278 


7606 


LDA 


R6, APT. AP. STATE 


027 A 


002A' 






027C 


2107 


LD 


R7, #READL 


027E 


0001 






0280 


A112 


LD 


R2, R1 


0282 


5F00 


CALL 


LIST_INSERT 


0284 












!R2 


: OBJ ID 






R3 


: LIST HEAD PTR 






R4 


: NEXT OB: PTR 






R5 


: PRIORITY PTR 






R6 


: STATE PTH 






R7 


; STATE VALUE ! 






! RESTORE LOCAL VARIABLES ! 


0286 


95F6 


POPL 


RR6, GRlb 


0288 


210B 


LD 


Rll, #REMOVED 


028A 


ABCD 







028C 5E0S 



ELSE IPROCESS STILL BLOCKED! 
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K2SE 

0290 


0292' 
8 DBS 


CLR Rll 


0292 


5E08 


FI ! END VALUE CHECK ! 

ELSE '.PROCESS STILL BLOCKED! 


0294 

0296 


0298' 

8D38 


CLR Rll 


0293 


5E08 


FI ! END INSTANCE CHECK ! 
ELSE fPROCESS STILL BLOCKED! 


029A 
029 C 


029E' 

8DB8 


CLR Rll 


029E 


5E08 


FI ! END HANDLE CHECK ! 

ELSE 'PROCESS STILL BLOCKED! 


02A0 

02A2 


02A4 ' 
8DB3 


CLR Rll 


02A4 


0B0B 


FI ! END HIGH HANDLE CHECK ! 

! RESET AP POINTER REGISTERS ! 
CP Rll, #REMOVED 


02A6 

02A8 


AECD 

5E06 


IF NE f PROCESS IS STILL BLOCKED ! 
THEN 


02AA 

02AC 


02B0' 

7616 


LDA R6, APT.AP.NEXT_AP(R1 ) 


02AE 


0020' 




02B0 


A171 


FI 

LD Rl, R7 


02B2 


E8B8 


OD 


0234 


3D28 


! DETERMINE IF ANY VIRTUAL PREEMPT 
INTERRUPTS ARE REQUIRED ! 

CLR R2 


02B6 


0B02 


PREEMPT CHECK: 

DO 

CP R2, #NR_CPU 2 


02B8 

02BA 


0004 

5E0E 


IF EC !aLL ready LISTS CHECKED! THEN 


02BC 

02BE 


02C2' 

5E08 


EXIT FROM PREEMPT_CHECK 


02C0 


0366' 





FI 

! CREATE PREEMPT VECTOR FOR VP'S ! 



02C2 


8D18 


CLR 


Rl 






DO IFOR Rl=l TO NR VP'S! 


02C4 


A910 


INC 


Rl 


02C6 


4B21 


CP 


Rl, APT.VP.NR_VP(R2) 


02C8 


0010' 










IF GT 


! PREEMPT VECTOR COMPLETED ! 


02CA 


5E02 


THEN 


EXIT 


02CC 


02D2' 






02CE 


5E08 






02D0 


02D8 ' 


FI 




02D2 


0DF9 


PUSH 


0R15, #TRUE 
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02D4: 


0001 






02D6 


E8F6 


OD 

! # TO 


PREEMPT ! 


02D8 


8D38 


CLR 


R3 


02DA 


6124 


LD 


R4, APT.VP.NR_VP(R2) 


02DC 


0010' 


! # OF 


VP'S ! 






! GET 


FIRST READY PROCESS ! 


02DE 


6121 


LD 


Rl, APT. READY LIST(R2) 


02E0 


0006' 










CHECK HDY LIST: 






DO 








! SEE 


IF READY LIST IS EMPTY ! 


02E2 


0B01 


CP 


Rl, #NIL 


02E4 


FFFF 


IF EO 


!LIST IS EMPTY! 


02E6 


5E0E 


THEN 


EXIT FROM CHECK_RDY_LIST 


02E8 


02EE' 






02EA 


5E08 






02EC 


0324' 


FI 




02EE 


4D11 


CP 


A?T.AP.STATE(R1 ) , ^RUNNING 


02F0 


002A' 






02F2 


0000 


IF EO 


!PROCESS IS RUNNING! 


02F4 


5E0E 


THEN 


! DON'T PREEMPT IT! 


02F6 


030C ' 






02F8 


6115 


LD 


R5, APT.AP.VP_ID(R1) 


02FA 


002E' 










! COMPUTE LOCATION IN PREEMPT VECTOP 


02FC 


4325 


SUB 


R5, APT.VP.FIRST(R2) 


02FE 


0014' 






0300 


74F6 


LDA 


R6, R15(R5) 


0302 


0500 






0304 


0D65 


LD 


0R6, ffFALSE 


0306 


0000 






0308 


5E08 


ELSE 


! PREEMPT IT ! 


030A 


030E' 






030C 


A930 


INC 


R3 






FI 




030E 


AB40 


DEC 


R4 


0310 


0B04 


CP 


R4, #0 


0312 


0000 


IF EO 


!ALL VP'S VERIFIED! 


0314 


5E0E 


THEN 




0316 


031C' 






0318 


5E08 


EXIT FROM CHECK RDY LIST 


031A 


0324' 


FI 








! GET 


NEXT AP IN READY LIST ! 


031C 


6110 


LD 


R0, APT.AP.NEXT_AP(R1^ 
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031£ 


0020' 




0320 


A101 


LD HI , R0 


0322 


E8DF 


OD !END CHECK RDY LIST! 

! SET NECESSARY PREEMPTS ! 


0324 


6124 


LD R4, APT.VP.NR_VP(R2) 


0326 


0010' 




0328 


6121 


LD Rl, APT.yP.FIHST(R2) 


032A 


0014' 


SEND PREEMPT: 
DO 


032C 


97E0 


POP R0, 0R15 

! CHECK TEMPLATE ! 


032E 


0B00 


CP R0 , #TRUE 


0330 


0001 


IF Eg !CAN BE PREEMPTED! 


0332 


5E0E 


THEN 


0334 


0350' 




0336 


0B03 


CP R3, #0 


0338 


0000 


IF GT ! preempts REOUIRED 


033A 


5E02 


THEN ! PREEMPT IT! 


033C 


0350' 


!SAVE ARGUMENTS! 


033E 


93F1 


PUSH OR15, R1 


0340 


91F2 


PUSHL GE15, RR2 


0342 


93F4 


PUSH 0R15, R4 


0344 


5F00 


CALL SET_PREEMPT 


0346 


0000>s 


!Pl: ¥P ID! 

! RESTORE ARGUMENTS ! 


0348 


97F4 


POP R4, GR15 


034 A 


95F2 


POPL RR2, 0R’15 


034C 


97F1 


POP Rl, 0R15 


034E 


AB30 


DEC R3 

FI 
FI 


0350 


A911 


INC Rl, #2 


0352 


AB40 


DEC R4 


0354 


0B04 


CP R^, «0 


0356 


0000 


IF EO ! STACK RESTORED! 


0358 


5E0E 


THEN 


035A 


0360' 




035C 


5E08 


EXIT 


035E 


0362' 


FI 


0360 


S8E5 


OD !END SEND PREEMPT! 

! CHECK NEXT READY LIST ! 


0362 


A921 


INC R2, #2 


0364 


E8A8 


OD !END PREEMPT CHECK! 
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! UNLOCK APT ! 



0366 


7604 


LDA 


R4. APT. LOCK 


0368 


0000' 






036A 


6F00 


CALL 


K_UNLOCK 


036C 


0000’!' 










! RESTOPE SUCCESS CODE 


036E 


H100 


LD 


R0, #SUCCE£DED 


0370 


0002 


FI 








! RESTORE STACK ! 


037^ 


010F 


ADD 


R15, #SIZEOF TEMP 


0374 


0012 






0376 


9E0S 


RET 




0378 




END TC 


advance 
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i?378 TC AWAIT PROCBDUR 

CHECKS USER SPECIFIED VALUE 

- AGAINST CURRENT EVSNTCOUNT 

=»' VALUE. IF USER VALUE IS LESS - 

- THAN OP equal EVENTCOUNT THEN- 



- CONTROL IS RETURNED TO USER. - 
ELSE USSR IS RLOCKED UNTIL - 
EVENT OCCURRENCE. 

3^*^ »|C 2^ S|%3|C S|&#^C 3^ #^C 3yS 3^ Sfi 3gS3|S 3|% 3|C «|* 3^33^ 3|S 3^ 3^ 

’i' PARAMETERS : ’i' 

Rl: HANDLE POINTER 
R2 : INSTANCE (EVENT ^ 

RR4: SPECIFIED VALUE - 

V 5? ^« =!« V ^ 5!5 5!s :?5 a? 3(t s)t sjt ^i« V ^ 5? Si* >:« V sp W V 

’i' RETURNS : 

- R0; SUCCESS CODE - 

^«:St 5)t vast a?^«^«5)tSisVJi<5!e»!eiit Sit Vjpj;ss;«jpjic Jit JfJit ? 



ENTRY 



! ESTABLISH STACK FRAME FOR 

temporary variables. ! 



0378 


030F 


SUB 


R15, #SIZEOF TEMP 


037A 


0012 


! SAV 


S INPUT PARAMETERS ! 


037C 


6FF1 


LD 


TEMP.HANDLE_PTR(R15 ) , Rl 


037E 


0000 






0380 


6FF2 


LD 


TEMP.EVENT_NR(R16 U R2 


0382 


0002 






0384 


5DF4 


DDL 


TEMP.EVENT_VAL(R15) , RR4 


0386 


0004 










! LOCK APT ! 


0388 


7604 


LDA 


R4, APT. LOCK 


038A 


0000' 






038C 


5F00 


CALL 


K_LOCK 


038E 


0000V 










! RETURNS WHEN APT IS LOCKED ! 






! GET 


CURRENT EVENTCOUNT ! 


0390 


5F00 


CALL 


MM_READ_EVENTCOUNT 


0392 


0000=5' 







!Rl: HANDLE POINTER 
R2: INSTANCE 
RETURNS : 

R0;SUCCESS_CODE 
RR4; EVENTCOUNT! 

0394 0B00 CP R0, #SUCCEEDED 
0396 0002 

0398 5E0E IF EQ THEN 
039A 0440' 

! DETERMINE IF REQUESTED EVENT 
HAS OCCURRED ! 



7't 



05yc 


54F6 


LDL RR6, TEMP. EVENT VAL(R15) 


e39E 


0004 






03A0 


9046 


OPL RR6, RR4 






IF GT 


! EVENT HAS NOT OOOURRED! 


03A2 


5E02 


THEN 


!BLOOK PROOESS! 


03A4 


0440' 










! identify PROOESS ! 


03A6 


5F00 


OALL 


RUNNING_VP ’RETURNS: 


03A8 


0000’!' 












Rl:VP ID 








R3:0PU 






! SAVE RETURN VARIABLES ! 


03AA 


6FF1 


LD 


TEMP.ID_VP(R15) , R1 


03AC 


0008 






03AE 


6FF3 


LD 


TEMP. CPU_NUM(R15) , R3 


03B0 


000A 






03BH 


6118 


LD 


R8, APT.RUNNING_LIST(R1^ 


03B4 


0002' 










! RESTORE REMAINING ARGUMENTS ! 


03B6 


61F2 


LD 


R2, TEMP.EVENT_NR(R15) 


03B8 


0002 






03BA 


61F1 


LD 


Rl, TEMP.HANDLE_PTR(R15) 


03BC 


0000 










! SAVE EVENT DATA ! 


03BS 


5414 


LDL 


RR4, HANDLE_VAL.HIGK(R1) 


03C0 


0000 






03C2 


5D84 


LDL 


APT. AP. HANDLE ( R8 ) , RR4 


03C4 


0030' 






0306 


6114 


LD 


R4, HANDLE_VAL.L0'J/(R1^ 


0308 


0004 






03OA 


6F84 


LD 


ART. AP. HANDLE [8 J (R8) , R4 


0300 


0034' 






03OE 


6F82 


LD 


APT.AP.INSTANOE(Re) , R2 


03D0 


0036' 






03D2 


54F6 


LDL 


RR6, TEMP.EVENT_VAL(R15^ 


03D4 


0004 






03D6 


5D86 


LDL 


APT.AP.VALUE(Re) , RR6 


03DS 


0038' 










! REMOVE PROOESS FROM READY LIST 


03DA 


6181 


LD 


Rl, A?T.A?.AFFINITY(RS) 


03DO 


0020 ' 






03DE 


6112 


LD 


E2, APT.READY_LIST(R1 ) 


03E0 


0006' 










! SEE 


IF PROOESS IS FIRST 






ENTRY IN READY LIST ! 


03E2 


CM 

CD 

CD 


OP 


P.2, Rg 






IF EQ 


! INSERT NEW READY LIST HEJ^E 


03E4 


5E0E 


THEN 




03E6 


03F4' 






03E8 


6183 


LD 


R3, APT.AP.NEXT_AP(H81 


03EA 


0020' 
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03EC 


6F13, 


LD 




APT .READT_LIST(H1 ) , R3 


03ES 


0006 








03F0 


5E08 


ELSE 


'.DELETE FROM LLST BODY! 


03F2 


040E ' 


DO 






03F4 


6123 


LD 




R3, AFT.AF.NEXT_AF(R2) 


03F6 


0020' 








0318 


8B83 


CP 




P3, R8 






IF 


EC 


IFOUND ITEM IN LIST! 


03FA 


5E0E 


THEN 




03FC 


040A' 








03FE 


6183 




LD 


R3, APT.AF,NEXT_AP(R81 


0400 


0020' 








0402 


6F23 




LD 


APT.AF .NEXT_AP(R2) , R3 


0404 


0020' 








04.06 


5E08 




EXIT 


0408 


040E ' 


FI 






040A 


A132 


LD 




R2, R3 


040C 


E8F3 


OD 










FI 










’THREAD 


PROCESS IN BLOCKED LIST! 


040E 


A182 


LD 


R2 


, R8 


0410 


7603 


LDA 


R3 


, AFT.BLOCKED_LIST 


0412 


000A' 








0414 


7604 


LDA 


R4 


, APT. AP.NEXT_AF 


0416 


0020' 








0418 


7605 


LDA 


R5 


, APT.AP.PRI 


041A 


0028 ' 








041C 


7606 


LDA 


R6 


, apt. AP. STATS 


041E 


002A' 








0420 


2107 


LD 


R7 


, ^BLOCKED 


0422 


0002 








0424 


5F00 


CALL 


LIST INSERT !R2:05J ID 


0426 


0000’!' 









?.3:LIST H3AE FTP. 
R4;NSXT OBJ FTP 
P.b:FP10PITY FTP. 
R6;STATE FTP 
R7:STATE ! 

! GET CURRENT VP ID ! 



0428 


61F1 


LD Rl, TEMP.ID_VP(R15 ) 


042A 


0008 




042C 


61F3 


LD R3, TEMP.CPU_NUM(R15) 


042E 


000A 


! SCHEDULE FIRST READY PROCESS ! 


0430 


5F00 


CALL TC_GETWORK !R1:VP_ID 


0432 


0000' 


R3:CPU 

! UNLOCK APT ! 


0434 


7604 


LDA R4, APT. LOCK 



14k: 



0436 0000' 

0438 5F00 CALL K_UNLOCK 

043A 0000=p 



! RESTOBE SUCCESS CODE 



043C 


2100 


LD 


P0, #SUCCE£DED 


043E 


0002 


FI 








FI 








! RESTORE STACK ! 


0440 


01 0f 


ADD 


R15, tfSIZEOF TEMP 


0442 


0012 






0^44 


9Eee 


RET 




0446 




END TC 


_AWAIT 
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4J4;4:6 



PROCESS_CLASS PROCEDURE 

T J(i *|*S^ yfi «|« »|* 3^« *|S S|% SfC «|« 2|« «i« ?iS 

reads security access 

- CLASS OE CURRENT PROCESS 

- IN APT. CALLED SEG ’•* 
MGR AND EVENT MGR 

9i( 9^ 9,c V ^ >i( V Sr ^ ^ ^ ^ ^ 



=? LOCAL VARIABLES; - 

'i' Rl: VP ID ’=' 

R5: PROCESS ID 

3^« 5J« ^ ^ ^ ^ ^ ^ ^ *1* ^ ^ ^ 



’P RETURNS : 

RR2: PROCESS SAC 

•*•5^5 SgS 5|« ^ i^S 3^ SgS 3»5 SJS 5gt 3i* 2^ 5J» 3|5 S,S 3|5 S^S Sfi f 







ENTRY 




0446 


7604 


LDA 


R4, APT. LOCK 


0448 


0000' 






044 A 


5E00 


CALL 


K_LOCK !R4:''aPT.L0CK 


044C 


0000’S 






044E 


5E00 


CALL 


RUNNING_VP (RETURNS ; 


0450 


0000^* 




Rl;VP ID 








R3:CPU #! 


0452 


6115 


LD 


R5,APT.RUNNING_LIST(R1 


0454 


0002' 






0456 


5452 


LDL 


RR2,APT.AP.SAC(R5) 


0458 


0024' 










! UNLOCK APT ! 


045A 


7604 


LDA 


R4. APT. LOCK 


045C 


0000' 






045E 


5F00 


CALL 


K_UNLOCK 


0460 


0000’S 






0462 


9E08 


RET 




0464 




END PROCESS CLASS 



14.4 



0464 



0464 
0466 

0465 
046 A 
046C 
046E 



0470 

0472 

0474 

0476 

0478 
047 A 
047C 
047E 
0^80 
0432 



GET_DJBfi_NUf^BER PROCEEUfiE 



OBTAINS DBR NUMBER EP.OM APT 
FOR THE CURRENT PROCESS. 

’i' CALLEE B^ segment MANAGER 



^ *1? S|* 3g«Si« 5J6 Jf5 ^ SjJ 3|S 3*t S^t S'fi 3^ 3|C Sfi Sfi S^? 3^ ifi 5^5 S^S SJ? 3|« 3^ SgS 



V 

5? 

5»C 



’i' LOCAL VARIABLES: - 

Pi: VP ID 

R5: PROCESS ID - 

9p 3^ 3;c 3^ 3^ s;c 3^ 3^ 3;: 3;e 3^ 3^ 3^ 3;c 3^ 3;c 3^ 3^ 3;e 3^ 3^ 3^ 3^ 3^ 3^ 3^ 3^ 3^ 3;e 3;e 3^ 3^ 

RETURNS: 

’•' Rl: DBP NUMBER - 

sic3i:7ii3!e3f3!CwWWSlcWVW>l‘>l‘WWVW>l‘V>!‘WV J 



ENTR*^ 

!NOTE: DBR # IS ONLY VALID WHILE PROCESS 
IS LOADED. THIS IS NO PROBLEM IN SASS 
AS ALL PROCESSES REMAIN LOADED. IN A 
MORE GENERAL CASS, THE DBR ^ COULD ONLY 
BE ASSUMED CORRECT WHILE THE APT IS LOCKED! 



7604 


LDA 


R4, APT. LOCK 


0000' 

5F00 


CALL 


K_LOCK !R4:''aPT.10CK! 


0000’!' 

5F00 


CALL 


RUNNING_VP ’RETURNS: 


0000’!' 






6115 


LD 


Rl:VP ID 
R3:CPU #! 
R5,APT.RUNNING_LIST(R1 


0002' 

6151 


LD 


Rl .APT. AP.DBR(R5) 


0022' 


! UNLOCK APT ! 


7604 


LDA 


R4, APT. LOCK 


0000' 

5F00 


CALL 


K_UNLOCK 


0000’!' 

9E08 


RET 





END GET DBR NUMBER 



END TC 
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APPENDIX C - EISTHIDUTED MEMORY MANAGER LISTINGS 



Z8000ASM H.02 

LOG OBJ CODE STMT SOURCE STATEMENT 



SLISTON STTY 




DIST_MM MODULE 




CONSTANT 




CREATE CODE 


= 50 


DELETE CODE 


= 51 


ACTIVATE CODE 


= 52 


DEACTIVATE CODE 


= 53 


SWAP IN CODE 


= 54 


SWAP"OUT_CODE 


= 55 


NR CPU 


= 2 


NR KST ENTRY 


= 54 


MAX SEG SIZE 


= 128 


MAX DBR NO 


= 4 


KST SEG NO 


= 2 


NR OF KSEGS 


= 10 


BLOCK SIZE 


= 8 


MEM AVAIL 


= ^F00 


G AST LIMIT 


= 10 


INS'^ANCEI 


= 1 


INSTANCS2 


= 2 


INVALID INSTANCE 


= 95 


SUCCEEDED 


= 2 



TYPE 

H_ARRAY 
COM MSG 
ADDJ?SSS 



ARRAY [3 WORDJ 
ARRA^ [16 BYTE] 
WORD 



G AST_REC RECORD 

TUNIOnE_ID LONG 

GLOEAL_ADDR ADDRESS 

P_L_ASTE_NO WORD 

flag word 

PAH_ASTE WORD 

NR_ACTIVE WORD 

NO_ACT_DEP BYTE 

SIZEl BYTE 

PG_TBL ADDRESS 

ALIAS TBL ADDRESS 



SEOUENCER LONG 
EVENTl LONG 
EYENT2 LONG 

J 
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MM ?P ID 



;JORD 



SEG_APRAY ARRAY [MAI_SEG_S I ZE 3YTEJ 

$SECTION D_MM DATA 
GLODAL 

MM_CPTT_TBL ARRAY [NR_CPU MM_7P_IDJ 

^SECTION AVAIL_MEM 
INTERNAL 

! NOTE: MEM_POOL IS LOCATED IN 
CPU LOCAL MEMORY. ! 

0000 MEM_POOL ARRAY [MEM_AVAIL BYTEJ 



GLOBAL 

! NOTE: NEXT_BLOCK IS USED IN THE MM_AIL0CATE 
STUB AS AN offset POINTER INTO THE FLOCK 
OF ALLOCATABLE MEMORY. IT IS INITIALIZED 
IN BOOTS TxRAP LOADER. ! 

0F00 NEXT_BLOCK WORD 

SSECTION MSG FRAME_DCL 
INTERNAL 

!NOTE: THESE RECORDS ARE ■’OVERLAYS" OR "FRAMES" USED 
TO DEFINE MESSAGE FORMATS. NO MEMORY IS ALLOCATED ! 
$ABS 0 



0000 


create_msg 


RECORD 


fCR CODE 
CE MM HANDLE 

CE entry no 
CE FILL 
CE SIZE 
CS_CLASS 


WORE 

H_ARRAY 

SHORT integer 

BYTE 

WORE 

LONG] 


0000 


SABS 0 
DELETE MSG 


RECORD 


[DE CODE 
DE MM HANDLE 
DS ENTRY NO 
DE FILL 


WORD 
H ARRAY 
SHORT INTEGER 
ARRAY [7 BYTE] 



0000 



$ABS 0 

ACTIVATE MSG 



RECORD [ACT_CODE WORE 

A_DBR_NO WORE 

A MM HANDLE H ARRAY 



A ENTRY_NO 
A~SEGMENT NO 
A FILL 



SHOET_ INTEGER 
SK0RT_INTEGER 

long] 
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0e00 



0000 



0000 



0000 



0000 



0000 



SAES 0 

DEACTIVATE MSG 



$ABS 0 
SWAP IN MSG 



$A£S 0 

SWAP OUT MSG 



$ABS 0 

RET sue CODE 



SABS 0 

R ACTIVATE ARG 



RECORD [DEACT CODE 


WORD 


D DER NO 


WORD 


D MM HANDLE 


H_ARRAY 


1— t 


ARRAY [3 


RECORD [S IN CODE 


WORE 


SI MM HANDLE 


H ARRAY 


SI DER NO 


WORD 


SI ACCESS AUTH 


[ BYTE 


SI FILLl 




SI_FILL 


ARRAr [2 


RECORD [S OUT CODE 


WORD 


SO DBR NO 


WORD 


SO MM HANDLE 


H ARRAY 


SO_FILL 


ARRAY [3 


RECORD [sue CODE 


BYTE 


SC FILL 


ARRAY [1 


J 



RECORD [R sue CODE 


B'^TE 


R~FILL 


BYTE 


R MM HANDLE 


H ARRAY 


R CLASS 


LONG 


R SIZE 


WORD 


R"FILL1 


WORD] 



WORD] J 



WCRDJ J 



WORD ] J 



5 BTTEJ 



SABS 0 

MM_HANDLE RECORD 

[ID LONG 

ENTRY NO WORD 

j 
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EXTL’RNAL 



G_AST_LOCK WORD 

G_AST ARRAY LG_AST_L1MIT G_AST_RECJ 



E_LOCK 


PROCEDURE 


K_UNLOCK 


PROCEDURE 


GET_CPU_NO 


PROCEDURE 


SIGNAL 


PROCEDURE 


WA I T 


PROCEDURE 
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GLOBAL 

$SECTION D_MM_PROC 






0K00 020F 
0002 0010 
0004 AlFD 



MM_CREATJ:J_ENTRY PROCEDURE 

>»= interface between seg mgr 

^ (CREATE_SEG PROCEDURE) AND 
^ MMGR PROCESS ( CREATE_ENTRY ^ 
PROCEDURE). ARRANGES AND 
^ PERFORMS I PC. 

S|C^» ifi ijji 3|( ?JC )j|* 9|S SJl* SgC Sy* 3^ S^C 3|« SJC 3JS 3^ Si« 3i» ifi 



yfi 


REGISTER USE: 


5? 




PARAMETERS 


s? 




R0:SUCCESS CODE (RET) 






RltHPTR (INPUT) 






R2:ENTPT NO (INPUT) 






R3:SIZE IlNPUT) 


V 




RR4:CLASS (INPUT) 


a? 




LOCAL USE 






R6:MM HANDLE ARRAY ENTRY 


*1* 




RB:''COM MSGBUF 






R13:''C0M MSGBUF 






:^3is:^3is 



ENTRY 

’USE stack for MESSAGE! 
SUB R15,#SIZE0F COM_MSG 



LD R13,R15 ! ''COM_MSGBUF ! 



IFILL COM_MSGEUF (LOAD MESSAGE). CREATE MSG 
FRAME IS BASED AT ADDRESS ZERO. IT IS 
OVERLAID ONTO C0M_MSGBUF FRAME BY INDEXING 
EACH ENTRI (I.E. ADDING TO EACH ENTRY) THE 
base address OF COM MSGBUF! 



0006 4DD5 LD 

0008 0000 
000A 0032 
000C 3116 LD 

000E 0000 
0010 6FD6 LD 

0012 0002 
0014 3116 LD 

0016 0002 
0018 6FD6 LD 

00 lA 0004 
001C 3116 LD 

001E 0004 
0020 6FD6 LD 

0022 0006 
0024 6FD2 LD 



CREATE_MSG.CR_C0DE(R13) ,#CREATE_C0DE 

R6,R1(#0) !INDET TO MM_HANDLE ENTRY! 
CREATE_MSG.CE_MM_HANDLE[0J (R13) ,R6 
R6.R1(#2) 

CR£ATE_MSG.CE_MM_HANDLSL1 j (R13) ,R6 
R6,R1(#4) 

CREATE_MSG.CE_MM_HANDLE12J (R13) ,R6 
CREATE MSG.CE ENTRY N0(R13),R2 



0026 


0008 






0028 


5rD4 


LDL 


CRSATS_MSG.CE_CLASS (R13) ,RR4 


002A 


000C 






002C 


6FD3 


LD 


CREATE_MSG,CE_SIZE(R13) ,R3 


002E 


000A 






0030 


AIDS 


ID 


R8,R13 


0032 


5F00 


CALL 


PEREORM_IPC !R8: "COM_MSGBUF! 


0034 


018C' 










IRETRIEVE SUCCESS CODE EROM RETURNEE MESSAGE! 


0036 


8D08 


CLR 


R0 


0038 


60D8 


LDB 


RL0,RET_SUC_CODE .SUC_CODE ( 313 ) 


003A 


0000 






003C 


010F 


ADD 


Rl5,ffSIZE0F COM_MSG !P.ESTOR£ STACK STATE! 


003E 


0010 






0040 


9£08 


RET 




0042 


END 


mm_create_entrt 
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MM_DEIi;TE_SNTRT PROCEDURE 

J v VW ^ V V W^ic Ws»s i,s V ^ 

interface retween SEG mgr ’i' 

’i' (DELETE_SEG PROCEDURE) AND ^ 

^ MMGR (DELETE_ENTRY PROCEDURE).- 
-ARRANGES AND PERFORf^S IPC. 

^ 9(c ^ ^ ?;c s;; :;c 3^ ^ ^ ^ 9;c V 39 c 3$; s;; 3}c ;i;c 

REGISTER USE: 

’J' PARAMETERS ’=' 

’ R0 :SUCCESS_CODE(RET) 

R1 :HPTR( INPUT) 

>i' R2 :£NTRY_NO( INPUT) 

LOCAL USE - 

’i' R6:MM_HANDLE ARRAY ENTRY - 

R8:"C0M_MSGBUF 
R13:"C0M_MSGBUF 

3|* 3|» 3|C Sifi 3|S 3|S 3|S 3,( 3jfi 3|C 3|S 3|C «i« SyC S|« 3|S 3|* 3^ Sfi 3^% 3y* 3|* 3|« 3|« 39* ^g* 3gS 3^ 3g^ | 

ENTRY 

!USE STACK FOR MESSAGE! 



0042 

0044 


030F 

0010 


SUB 


0046 


AlFD 


LD 



Rl3,Rlb ! COM_MSGPUF ! 

IFILL COM_MSGEUF (LOAD MESSAGE). DELETE_MSG FRAME 
IS BASED AT ADDRESS ZERO. IT IS OVERLAID ONTO 
COM_MSGBUF F^^AME BY INDEXING EACH ENTRY (I.E. ADD- 
ING TO EACH ENTRY) THE BASE ADDRESS OF COM MSGBUF! 



0048 


4DD5 


LD 


DELETE_MSG. 


004 A 


0000 






004C 


0033 






004E 


3116 


LD 


R6,P. 1(^*0) 


0050 


0000 






0052 


6FD6 


LD 


D£LETE_MSG. 


0054 


0002 






0056 


3116 


LD 


R6,R1(#2) 


0058 


0002 






005A 


6FD6 


LD 


delste_msg. 


005C 


0004 






005E 


3116 


LD 


R6.P1 (# 4 ) 


0060 


0004 






0062 


6FD6 


LD 


delete_msg.: 


0064 


0006 






0066 


6FD2 


LD 


DELSTE_MSG . 


0068 


0008 






006A 


A1D8 


LD 


R8.R13 


006C 


5F00 


CALL 


PERFORM_IPC 


006E 


018C ' 










’RETRIEVE SUCCESS 


0070 


8D08 


CLR 


R0 


0072 


60D8 


LDB 


RL0,RET_SUC 


0074 


0000 






0076 


010F 


ADD 


R15,#SIZE0F 


0078 


0010 






007 A 


9E08 


RET 




007C 


END 


MM DELETE ENTRY 
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et;7c 



007C 

Z07E 

0080 

0082 



0084 

0086 

0088 

008A 

008C 

008E 

0090 

0092 

0094 

0096 

0098 

009A 

009C 

009E 

00A0 

00A2 



MM activate fhoceture 

V interface between sec mgr - 

(MAKE KNOWN PROCEDURE^ ANE 

- ^^MGR “ (ACTIVATE PROCEDURE). - 

- ARRANGES AND PERFORMS IPC . - 

5? jp 5?SfC W =!t V 5? sp V 5? S? a? V »!t V W 3? ’i' 55« W sp 5? sp S? ap S? 





REGISTER USE: 


aji 




PARAMETERS 


a? 




Rl:DBR NO(INPUT) 




3r 


R2:EPTR( INPUT) 


V 




R3; ENTRY NO 


ai* 


a? 


R4:S£GMENT NO 


a? 


a? 


R12-.RET HANDLE PTR 


a? 


aiS 


LOCAL USE 


V 


a;e 


R8:''C0M MSGBUF 


a? 


a;c 


R13:''C0M MSGBUF 


a? 


V 


RETURNS: 


a|i 


a«6 


RetSUCCESS CODE 




a;e 


RR2: CLASS 






R4:SIZE 


a? 



apapap^ppcpc VapjpapapvpcajeptJiesicpcaic^ppspsptap jj::9e5p5iCJie3itptpt;j: } 



ENTR"^ 

!USE STACK FOR MESSAGE! 

030F SUB R15,#SIZE0F COM_MSG 

0010 

AIFD LD R12,R15 ! "COM_MSGBUF ! 

! SAVE RETURN HANDLE POINTER ! 
93FC PUSH 0R15, Rl2 



!FILL COM MSGBUF (LOAD MESSAGE). ACTIVATE_MSG FRAME 
IS BASED“aT ADDRESS ZERO. IT IS OVERLAID ONTO 
COM_MSGBUF FRAME BY INDEXING EACH ENTR^ ( I .E . ADD- 
ING TO EACH ENTRTf) THE BASE ADDRESS OF COM MSGBUF! 



4DD5 


LD 


ACTIVATE_MSG. AC 


T_C0DE(R13^ ,#ACTIVAT 


0000 

0034 

6FD1 


LD 


ACTIVATS_MSG.A_ 


DBR_NO(R13) ,R1 


0002 

3126 


LD 


R6,R2(#0) 




0000 

6FD6 


LD 


ACTIVATE_MSG. A_ 


MM_HANDLE [0J (R13^ ,R6 


0004 

3126 


LD 


R6,R2(#2) 




0002 

6FD6 


LD 


ACTIVATE_MSG.A_ 


MM_HANDLSLU (R13) ,R6 


0006 

3126 


LD 


R6,R2(#4) 




0004 

6FD6 


LD 


ACTIVATE_MSG.A_ 


MM_HANDLS12J ( H13) , R6 
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eeA4 

00A6 

00A8 

00AA 

00AC 

00AE 

00B0 

00B2 

00B4 



00 B6 
00B8 
003A 
00BC 
00BE 
00C0 
00C2 
00C4 

00C6 

00C8 

00CA 

00CC 

00CE 

00D0 

00D2 

00D4 

00D6 

00D8 

00DA 



0008 






6EDB 


LDB 


ACTIVATE_MSG. A_ENTRY_N0(R13) ,RL3 


000A 






6EDC 


be 


ACTIVATE^MSG. A_SEGMENT_N0(R13' ,RL4 


000B 






AIDS 


LD 


R8,R13 


5E00 


CALL 


PERFORM_IPC ! (R8 :''COM_MSGBUF! 


018C ' 








! RESTORE RETURN HANDLE POINTER ! 


97EC 


POP 


R12, 0R15 




! update mm handle entry ! 


54D6 


LDL 


RR6 , R_ACTIVATS_ARG .R_MM_HANDLE( R13 ) 


0002 






5DC6 


LDL 


MM_HANDLE.ID(R12) , RR6 


0000 






61D5 


LD 


R6,R_ACTIVATE_ARG .R_MM_HANDLE 1 2J (R13) 


0006 






6FC6 


LD 


MM_KANDLE.ENTRT_N0(R12 ) , R6 


0004 








! RETRIEVE OTHER RETURN ARGUMENTS! 


8D08 


CLP 


R0 


60D8 


LDB 


RL0,R_ACTIVATE_ARG.H_SUC_CODE(R13) 


0000 






54D2 


LDL 


RR2,R_ACTIVATE_ARG.R_CLASS(R13) 


0008 






61D4 


LD 


R4,R_ACTIVATE_ARG.R_SIZE(E13) 


000C 






010F 


ADD 


R15,#SIZS0F COM_MSG 'RESTORE STACK STATE! 


0010 






9E08 


RET 





END MM activate 
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eeDA DEACTIVATE FROCEEUKS 

INTERFACE BETWEEN SEG f^GR - 

(TERI^INATE procedure) and '“ 

- rr^GR (deactivate procedure). - 
'•* arranges and performs ipc. 

’p register USE: ^ 

- PARAMETERS - 

RO :SUCCESS_CODE(RET) - 

R1 :DBR_N0( INPUT ) - 

RPtHPTRdNPUT) - 

LOCAL USE 

^ R6 :MM_HANDLE array ENTRY 

- R8 :''COM_MSG£UF 
’S' R13:''C0M_MSGBUF 



ENTRY 



O0DA 


030F 


!USE 

SUB 


OODC 

0ODE 


0010 

AIFD 


LD 



STACK FOR MESSAGE! 
R15,#SIZE0F COM_MSG 

R13,Rlb ! "COM_MSGEUF ! 



IFIIL COM_MSGEUF (LOAD MESSAGE). DEACTI VATE_MSG FRAME 
IS BASED AT ADDRESS ZERO. IT IS OVERLAID ONTO 
C0M_MSGBUF frame by INDEXING EACH ENTRY ( I .E . ADD- 
ING TO EACH ENTRY) THE BASE ADDRESS OF COM MSGBUF! 



00 E0 


4DD5 


LD 


deactivate. 


MSG.DEACT C0DS(R13^ , 


00E2 


0000 






#dsactivate,code 


00E4 


0035 








00E6 


6FD1 


LD 


deactivate. 


MSG.D_DBR_N0 (R13) ,R1 


00E8 


0002 








00EA 


3126 


LD 


R6,R2(#0) 


! INDEX TO MM, HANDLE ENTRY! 


00EC 


0000 








00EE 


6FD6 


LD 


deactivate. 


MSG.D,MM,EANDLE[0j (R13) ,R6 


00F0 


0004 








00F2 


3126 


LD 


R6,R2(#2) 




00F4 


0002 








00F6 


oFD6 


LD 


deactivate_ 


MSG.D_MM,HANDLE[1J (R13) ,R6 


00 Fe 


00 06 








00FA 


3126 


LD 


R6,P.2(ff4) 




00FC 


0004 








00FE 


6FD6 


LD 


deactivate. 


MSG. D_MM, HANDLE (2J (R13) , R6 


0100 


0008 








0102 


A1D8 


LD 


R8,R13 




0104 


5F00 


CALL 


PERFORM_IPC 


!R8: ''COM, MSGBUF! 


0106 


018C ' 
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IPJiTHIKVE SUCCESS CODE FROM RETURNED MESSAGE! 



feJlee 8D08 
iJlfeJA 60D8 
010C 0000 
010E 010F 
0110 0010 
011ii 9E08 
0114 END 



CLR E0 

LDB RL0,RET_SUC_COD£.SUC_CODE(P13) 

ADD R15,#SIZE0F COM_MSG IRESTOflE STACK STATS 
RET 

MM DEACTIVATE 
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0114 



0114 

0116 

0118 



011A 
011C 
011E 
0120 
0122 
0124 
0126 
0128 
012 A 
012C 
012E 
0130 
0132 
0134 
0136 
0138 
013A 
013C 
013E 
0140 
0142 
0144 



MM S5VAP IN PROCEDURE 

interface between sec mgr (SM_’^ 

- SWAP IN PROCEDURE) AND MMGR - 
’ (SWAP_IN PROCEDURE). ARRANGES 
’i' AND PERFORMS IPC . - 

5|C5JS J,C 3|* SJC 3^ 2|« ^»3|« #|* 3^Z 5^ SyK iji Jj5 S|C #|* Sfi 5|» 



3JC 


REGISTER USE; 


3»* 




PARAMETERS 


3|2 




R0:SUCCESS CODE(RET) 


3i* 




Rl;DBK NO (INPUT) 


3^« 


y? 


P2;KPTR(INPUT) 


3J5 


yfi 


R3;ACCESS (INPUT) 


3|5 


3? 


LOCAL USE 


3^ 


3? 


R6;MM HANDLE ARRAY ENTRY 


V 


V 


R8;''C0M MSGBUF 


3.i 




R13:''C0M MSGBUF 


3?C 



Ws;ss;«3?a;c3pi;ea?:a;ea?:jica;«:5sa?:3?:>?:>?a;Oi6 5;c>?a?:3?a^a?a?;?^ap f 



ENTRT 

!USE stack for MESSAGE! 

030F SUB R15,#SIZEOF COM_MSG 

0010 

AIFD LD R13,R15 1 ''COM MSGBUF ! 



!FILL COM MSGBUF (LOAD MESSAGE). SWAP_IN_MSG FRAME 
IS BASSD"aT address zero, it IS OVERLAID ONTO 
COM MSGBUF FRAME BY INDEXING EACH ENTRY (I.E. ADD- 



SWAP_IN_MSG.S_IN_C0DE(R13) ,#SWAP_IN_CODE 

R6,P.2(#0) ’INDEX TO MM_HANDLE ENTRY! 
SWAP_IN_MSG.SI_MM_HANDLE10J (R13) ,R6 
R6,P2(#2) 

SWAP_IN_MSG.SI_MM_HANDLE[1J (R13> ,R6 
R6,R2(#4) 

SWAP_IN_MSG.SI_MM_KANDLE[2J (R13) ,R6 
SWAP_IN_MSG.SI_DBR_N0(R13) ,R1 
SWAP IN MSG. SI ACCESS AUTH(Rl3^PL3 





ING TO 


4DD5 

0000 

0036 


LD 


3126 

0000 


LD 


6FD6 

0002 


LD 


3126 

0002 


LD 


6FD6 

0004 


LD 


3126 

0004 


LD 


6FD6 

0006 


LD 


6FD1 

0008 


LD 


6EDB 

000A 


LDB 


klDB 


LD 


5F00 
018C ' 


CALL 



PS,R13 
PERFORM IPC 



!R8: COM MSGBUF! 
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I'^.iJTRIKVE SUCCESS CODE FROM RETURNEE ^^ESSACE! 



65146 


eD08 


CLR 


H0 


0148 

014A 


60D8 

0000 


LDB 


RL0,RET_SUC_CODE.SUC_COEE(R13) 


014C 

014E 


010F 

0010 


ADD 


R15,#SIZE0E COM_MSG IRESTORS STACK 


0150 


9E08 


RET 




0152 


END 


MM_SWAP_IN 
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eib2 PROCEEURE 

interface between SEG r^GR (SM_’i' 

SWAP_OUT PROCEDURE) AND r^MGR 
(SWAP_OUT PROCEDURE). ARRANGES- 
AND PERFORMS IPC. ’i' 

3^)^ 9^ ^ 3JC 3^ 3^ ?;c 3^ ;;c ^ s;c 9iC );c V ^ ^ ’ic 7 ^ 3jc 3^ 

- REGISTER USE; - 

^ PARAMETERS ’s' 

’i' R0:SUCCESS_CODE(RET) 

- RlrDBR NO( INPUT) - 

R2:HPTR(INPUT) 

LOCAL USE - 

- R6:MM HANDLE ARRAY ENTRY - 

=!' Re :*'C0M_MSGBDF 

R13;''C0M_MSGBUF 

ENTRY 

!USE STACK FOR MESSAGE! 



0152 


030F 


SUB 


R15,#SIZE0F 


COM_MSG 


0154 

0156 


0010 

AlFD 


LD 


R13.R15 ! 


''COM MSGBUF ! 



!FILL COM MSGEUF (LOAD MESSAGE). SWAP_OUT_MSG FRAME 

IS based”at address zero, it is overlaid onto 

COM_MSGBUF FRAME BY INDEXING EACH ENTRY (I.E. ADD- 
ING TO EACH ENTRY) THE BASE ADDRESS OF COM MSGEUF! 



0158 

015A 

015C 


4DD5 

0000 

0037 


LD 


SWAP_OUT_MSG. 


015E 

0160 


3126 

0000 


LD 


R6,R2{#0) !I 


0162 

0164 


6FD6 

0004 


LD 


SWAP_OUT_MSG. 


0156 

0168 


3126 

0002 


LD 


R6,R2(<#2) 


016A 

016C 


6FD6 

0006 


LD 


SWAP_OUT_MSG. 


016E 

0170 


3126 

0004 


LD 


R6,R2(#4) 


0172 

0174 


6FD6 

0008 


LD 


SWAP_OUT_MSG. 


0176 

0178 


6FD1 

0002 


LD 


SWAP_OUT_MSG. 


017A 


A1D8 


LD 


R8,R13 


017C 

017E 


5F00 

018C' 


CALL 


PERFORM_IPC 



S_0UT_C0DE(R13) , #SWAP_OUT_COD£ 

NDEX TO MM_HANDLE ENTRY! 
SO_MM_HANDLE[0] (R13),R6 

SO_mm_HANDLE[1J (R13^ ,R6 

S0_MM_EANDL£[2J (R13) ,RG 
S0_D£R_N0(R13) ,R1 

!R8: ''COM MSGBUF! 
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IRSTRIEVE SUCCESS_CODE FROM RETURNED MESSAGE! 
0180 8D08 CIR fiO 

0182 80D8 LDB RL0 , P.ET_SUC_CODE . SUC_CODE ( R13 ) 

0184 0000 

0186 010F ADD R15,#SIZE0F COM_i^SG IRESTORE STACK STATE 

0188 0010 
018A 9E08 RET 

018C END MM SWAP OUT 
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?18C 



018C 

018E 

0190 

0198 

0194 

0196 

0198 

019A 

019C 

019E 

01A0 

01A2 

01A4 

01A6 

01A8 

01AA 

01AC 

01AE 

01E0 

01£2 

01B4 

01B6 

eiB8 

01BA 



PEPEORM IPC PROCEEURE 

SERVICE ROUTINE TO ARRANGE AND - 
PERFORM IPC WITH THE MEM MGR PROC ’=' 

V 3p V ^ ^ ^ lit ^ ^ ^ >i< 9 7 >ic 3p :<< 3? 3;: 



¥ 


REGISTER USE: 


5? 


39 c 


PARAMETERS 


3?: 


nC 


R8: ''C0m_MSG(INPUT) 


3r 


V 


LOCAL USE 


3|5 


5? 


R1,R2: WORK REGS 


3? 


3JC 


R4: ''G AST LOCK 




5.S 


R13: ''COM MSGBUF 


3r 



:;^WVWfl‘3lfW^3ii3f3)i3!i3f.3itif3f3fs/iS)i:f3;it::)C3itsf^3f3)i3!C3f3!iif3f3fti: I 



93FD 


ENTRY 

PUSH 


0R15,R13 !''COM MSGBUF! 


5F00 


CALL 


GET_CPU_NO !RET-Rl;CPU_NO! 


0000=!' 

A112 


LD 


R2,R1 


6121 


LD 


R1 ,MM_CPU_TEL( R2) !MM_VP_ID! 


0000' 

7804 


LDA 


R4,G_AST_LOCK 


0000=!' 

5F00 


CALL 


K_LOCK 


0000V 

5F00 


CALL 


SIGNAL !R1 :MM_VP_ID,RS :''COM_MSGEUF 


0000V 

97FD 


POP 


R13,PR15 


AIDS 


LD 


R8,R13 !''COM MSGBUF! 


93FD 


PUSH 


PR15,R13 


5F00 


CALL 


wait !R8:''C0M_MSGEUF! 


0000=^' 

7504 


LDA 


R4,G_AST_LOCK 


0000V 

5F00 


CALL 


K_UNLOCK 


0000V 

97FD 


POP 


R13,0R15 


9E08 


RET 





END PERFORM IPC 
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ai3A 



01BA E331 
01BC 0006 



01BB 6104 
01C0 0F00' 
01C2 7642 
01C4 0000' 
01C6 8134 



01C6 6F04 
01CA 0F00' 
01CC 9E08 
01CE 



MM_ALLCCATS PROCEDURE 

’i' ALLOCATES BLOCKS OF CPU=«‘ 

LOCAL r^EMORY. EACH 
BLOCK CONTAINS 256 
BYTES OF MEMORY. 

^ :;c 3^ 2 JC 7^ ;gc ^ ^ ^ 

PARAMETERS: 

’i' R3: # OF BLOCKS 

RETURNS: 

R2: STARTING ADDR “s* 

LOCAL: 

^ R4: BLOCK POINTER 

ENTRr 

! NOTE: THIS PROCEDURE IS ONLY A STUB 
OF THE ORIGINALLY DESIGNED MEMORY 
ALLOCATING MECHANISM. IT IS USEE 
BY TEE PROCESS MANAGEMENT DEMONSTRATION 
TO ALLOCATE CPU LOCAL MEMO?. I FOR ALL 
MEMORY ALLOCATION REQUIREMENTS . IN AN 
ACTUAL SASS ENVIRONMENT, THIS WOULD 
BE BETTER SERVED TO HAVE SEPARATE 
ALLOCATION PROCEDURES FOR KERNEL AND 
SUPERVISOR NEEDS. (E.G., KERN EL_ALLOCATE 
AND SUPERVISOR_ALLOCATE ) . ! 

! COMPUTE SIZE OF MEMORY REQUESTED ! 

SLL R3, #BLOCK_SIZE 

! COMPUTE offset OF MEMORY THAT IS 
TO BE ALLOCATED ! 

LD R4, NEXT_BLOCK lOFFSET! 

LDA R2, MEM_POOL(R4) ! START ADDR! 

ADD R4, R3 lUPDATE OFFSET! 

! UPDATE OFFSET IN SECTION OF AVAILABLE 
MEMORY TO INDICATE THAT CURRENTLY 
REQUESTED MEMORY IS NOW ALLOCATED ! 

LD NEXT_BLOCK, R4 !SAVE OFFSET! 

RET 

END MM ALLOCATE 
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Pl 



JWLJ 



eiCE 



01CE 93F1 

01D0 7604 
01D2 0000»i‘ 
01D4 5F00 
01D6 0000=^ 

01D8 97F1 

01DA 6118 
01DC 0004 

01DE 5486 
01E0 0014’^ 

01E2 9464 



01E4 1606 
01E6 0000 
01E8 0001 

01EA 5D86 
01EC 0014’«' 



01EE 91F4 
01F0 7604 
01F2 0000’!' 
01F4 5F00 
01F6 0000=" 

01F8 95F4 
01FA 9E08 
01FC 



MM TICKET PROCEDURE 

RETURNS CURRENT VALUE OF =" 

=" SEGMENT SEQUENCER AND 
=" INCREMENTS SEQUENCER VALUE=" 

=" FOR NEXT TICKET OPERATION - 

=" PARAMETERS: 

- Rl: SEG HANDLE PTR 
=" RETURNS: 

=" RR4: ticket VALUE 
=" LOCAL VARIABLES: 

>" RR6: SEQUENCER VALUE =" 

=" R8: G_AST ENTRY # 

ENTRY 

! SAVE HANDLE PTR ! 

PUSH GR15, Rl 
! LOCK G_AST ! 

LDA R4, G_AST_LOCK 

CALL K_LOCK 

! RESTORE HANDLE PTR ! 

POP Rl, 0R15 
! GET G_AST ENTRY # ! 

LD R8, MM_HANDLE.ENTRY_NO(Rl) 

! GET TICKET VALUE ! 

LDL RR6, G_AST.SEQUENCER(R8) 

! SET RETURN REGISTER VALUE ! 

LDL RR4, RR6 
!ADVANCE SEQUENCER FOR NEXT 
TICKET OPERATION! 

ADDL RR6, #1 



! SAVE NEW SEQUENCER VALUE IN G_AST 
LDL G_AST.SEQUENCER(R8) , RR6 

! UNLOCK G_AST ! 

! SAVE RETURN VALUES ! 

PUSHL 0R15, RR4 
LDA R4, G_AST_LOCK 

CALL K_UNLOCK 

! RETRIEVE RETURN VALUES ! 

POPL RR4, OR15 
RET 

END MM TICKET 
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01PC 



01i’C 

01FE 

0200 

0202 

0204 

020fc) 

0208 
020 A 

020C 

020E 



0210 

0212 

0214 

0216 

0218 

021A 

021C 

021E 

0220 

0222 

0224 

0226 

0228 

022A 

022C 



MM_READ EVENTCOUNT PROCEDURE 

I :(c9gc3^]i;ic:^;;c9gc3tc:(cj)e9ic]p)iev3(cv svelte 

READS CURRENT VALUE OF THE 
^ EVENTCOUNT SPECIFIED £Y THE =" 

=** USER. 

PARAMETERS: 

Rl: SEG HANDLE PTR » 

R2: INSTANCE (EVENT #) 

’S' RETURNS: 

’i' RR4: EVENTCOUNT VALUE 

;;c:;c ^ jgc qc V :;c :;c jgc jgc :;c V :(( :;c Jic igc ;gc :((:(( sgc :;e :;c jgc jgc jgc 

LOCAL VARIABLES: 

RR6: SEQUENCER VALUE >=' 

R8: G_AST ENTRY # 

ENTRY 

! SAVE INPUT PARAMETERS ! 

93F1 PUSH 0R15, Rl 

93F2 PUSH 0R15, R2 

! LOCK G AST ! 

7604 LDA R4, G_AST_LOCK 

0000 *^ 

5F00 CALL K_LOCK 

00005 ? 

! RESTORE INPUT PARAMETERS ! 

97F2 POP R2, 0R15 

97F1 POP Rl, 0R15 

! GET G AST ENTRY # ! 

6118 LD R8, MM_EANDLE.ENTRY_N0(R1) 

0004 

! READ EVENTCOUNT ! 

! CHECK WHICH EVENT #. ! 

IF R2 



0B02 


CASE 


#INSTANCE1 THEN 


0001 

5E0E 

0224' 

5484 


LDL 


RR4, G_AST.EVENT1 (R8) 


0018’!' 

2100 


LD 


R0, "SUCCEEDED 


0002 

5E08 


CASE 


#INSTANC£2 TEEN 


023C' 

0B02 

0002 

5E0E 

0238' 

5484 


LDL 


RR4, G_AST.EVENT2(R8) 
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022E 
0230 
0232 
0234 
0236 
0238 
023 A 



023C 

023E 

0240 

0242 

0244 

0246 

0248 

024A 



0010^^ 

2100 


LD 


R0, #SUCCEEDED 


0002 

5E08 


ELSE 


.'INVALID INPUT! 


023C' 

2100 


LD 


R0, #INVALID_INSTANCE 


005F - 


FI 

f NOTE 


: NO VALUE IS RETURNED IF 




USER 


SPECIFIED INVALID EVENT 




! SAVE 


RETURN VALUES ! 


91F4 


PUSH! 


0R15, RR4 




! UNLOCK G AST ! 


7604 


LDA 


R4, G_AST_LOCK 


0000* 

5F00 


CALL 


K_UNLOCK 



! RESTORE RETURN VALUES ! 
95F4 POPL RR4, 8R15 

9E08 RET 

END MM READ E7ENTC0UNT 
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024A 



024A 

024C 

024E 

0250 

0252 

0254 

0256 

0258 

025A 

025C 



025E 

0260 

0262 

0264 

0266 

0268 

026A 

026C 

026E 

0270 

0272 

0274 

0276 

0278 



mm_advance procedure 

’i' DETERMINES G_AST OFFSET FROM 
SEGMENT HANDLE AND INCREMENTS 
THE INSTANCE(EVENT #) SPECIFIED - 
BY TEE CALLER. THIS IN EFFECT 
ANNOUNCES THE OCCURRENCE OF THE “i* 
^ EVENT. THE NEW VALUE CF THE 
EVENTCOUNT IS RETURNED TO THE 
^ CALLER. 

PARAMETERS : ’i* 

Rl: HANDLE POINTER 
’i' R2: INSTANCE (EVENT #) 

3^ ^ 9^ 9QC3gc >gc 3^ 3^ 3QC 9^ aic 99 c 3^ ^ 9QC 3^ 3^ sje 3ic 9^ 9^ 3j( age ^ ^ 

^ RETURNS: 

'i' RR2: NEW EVENTCOUNT VALUE - 

ENTRY 

! SAVE INPUT PARAMETERS ! 

93F1 PUSH 0R15, Rl 

93F2 PUSH GR15, R2 

! LOCK G AST ! 

7604 LDA R 4 T G_AST_L0CK 

000039C 

5F00 CALL K LOCK 

0000^^ 

! RESTORE INPUT PARAMETERS ! 

97F2 POP R2, PR15 

97F1 POP Rl, 0R15 

! GET G_AST OFFSET ! 

6114 LD R4, MM_HANDLE.ENTRT_NO(Rl) 

0004 

! determine INSTANCE ! 

IF R2 

0B02 CASE #INSTANCE1 THEN 

0001 
5E0E 
027C' 

5442 LDL RR2, G AST . EVENTl ( R4 ) 

0018=^ 

1602 ADDL P.R2, #1 

0000 
0001 

! SAVE NEW EVENTCOUNT ! 

5D42 LDL G_AST .EVENTl ( R4 ) , RR2 

0018^ 

2100 LD R0, ^SUCCEEDED 

0002 

5E08 CASE #INSTANCE2 THEN 
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H27A 


029E' 






227C 


0B02 






027 E 


0002 






0280 


5E0E 






0282 


029A' 






0284 


5442 


LDL 


RR2, G_AST.EVENT2(R4) 


0286 


0010’=' 






0288 


1602 


ADDL 


RR2, #1 


028A 


0000 






028C 


0001 










! SAVE NE’# EVENTCOUNT ! 


028E 


5D42 


LDL 


G_AST.EVSNT2(R4) , RR2 


0290 


0010’p 






0292 


2100 


LD 


R0, #SUCCEEDED 


0294 


0002 






0296 


5E08 


ELSE 


!INVALID INPUT! 


0298 


029E' 






029A 


2100 


LD 


R0, #INVALID_INSTANCE 


029C 


005F 










El 








! NOTE 


: AN INVALID INSTANCE VALUE 






WILL 


NOT AFFECT EVENT DATA ! 






I UNLOCK C- AST ! 


029E 


7604 


LDA 


R4, G_AST_L0CK 


02A0 


0000’!' 






02A2 


5F00 


CALL 


K_UNL0CK 


02A4 


0000V 






02A6 


9E08 


PET 




02A8 




END MM 


advance 



END DIST MM 
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APPENDIX D - GATE KEEPER LISTINGS 



ZSfe50k5ASM 2,02 

LOG OBJ CODE ST'^T SOURCE STATEf^ENT 



KERNEL_GATE_KEEPER MODULE 

$LISTON STTY 



CONSTANT 

ADVANCE_CALL := 

AWAIT_CALL := 

CREATE_SEG CALL := 

DELETB_SEG“cALL := 

MAKE_KNOWN_CALL 
READ_CALL := 

SM_SWAP IN CALL := 

?M_SWAP~OUT_CALL := 

TERMINA^E_CALL := 

TICKET_CALL := 

WRITE_CALL := 

WRITELN_CALL := 

CRLF_CALL := 

WRITE := 

WRITELN := 

CRIF : = 

MONITOR := 

REGISTER_BLOCK := 

TRAP_CODE_OFFSET := 

INVALID KERNEL ENTRY := 



1 

2 

3 

4 

5 

6 

7 

8 
9 



10 

11 

12 

13 

ZZYC& 


!PRINT 


CHAR! 


^0FC0 


’.PRINT 


MSG ! 


^0FD4 


! CAR R 


ET/LINE FEED! 


%A902 

32 

36 

:j^bad 







global 

GATE KEEPER ENTRY LABEL 



EXTERNAL 

ADVANCE 

AWAIT 

CREATE_SEG 
DELETE SEG 
MAKE KNOWN 

read" 

SM_SWAP_IN 

SM_SWAP_OUT 

terminate 

TICKET 
KERNEL EXIT 



PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

LABEL 



INTERNAL 

$SECTION KERNEL GATE PROC 



16S 



eee'fe) 



GATE KEEPER MAIN 



PROCEDURE 



0000 030F 
0002 0020 
0004 1CF9 
0006 010E 

0008 93F2 
000A 7D27 

000C 2DF2 

000E 93F2 

0010 31F2 
0012 0024 



0014 8C28 



0016 0£02 
0018 0001 
001A 5E0E 
001C 0028' 
001E 97F2 
0020 5F00 
0022 0000’!' 
0024 5E0S 
0026 010C' 
0028 0P02 
002A 0002 
002C 5E0E 
002E 003A' 
0030 97F2 
0032 5F00 
0034 0000’" 
0036 5E08 
0038 010C' 
003A 0P02 
003C 0003 
003E 5E0E 
0040 004C' 



ENT?’’’ 

GAT*E_KSEPER_ENTRr : 

! SAVE REGISTERS ! 

SUB R15, #REGISTER_BLOCX 

LDM (?R16, Rl, #16 

! SAVE NSP ! 

PUSH 0R15, R2 
LDCTL R2, NS? 

! RESTORE INPUT REGISTERS ! 

EX R2, ORlb 
! SATE REGISTER 2 ! 

PUSH GR15, R2 
! GET SYSTEM TRAP CODE ! 

LD R2, R15(#TRAP_C0DE_0FFSET) 

! REMOVE SYSTEM CALL IDENTIFIER FROM 
SYSTEM TRAP INSTRUCTION ! 

CLRB RH2 

! NOTE: THIS LEAVES THE USER VISI3LF; 

EXTENDED INSTRUCTION NUMBER IN R2 ! 

! DECODE AND EXECUTE EXTENDED INSTRUCTION 
IF R2 

! NOTE: THE INITIAL VALUE FOR REGISTER 2 
'VILL BE RESTORED WHEN THE APPROPRIATE 
CONDITION IS FOUND ! 

CASE #ADVANCE CALL THEN 



POP R2, 0R15 
CALL ADVANCE 

CASE #AWAIT CALL THEN 



POP R2, (?R15 
CALL AWAIT 

CASE # CREATE SEG CALL TEEN 



I 




I 






97F2 


POP 


R2, 0R15 




t?044 


5E00 


CALL 


CREATE_SEG 




0046 


0000V 








0046 


5E08 


CASS 


/fDELETE_SEG_CALL 


THEN 


004 A 


010C ' 








004C 


0E02 








004E 


0004 








0050 


5E0E 








0052 


005E' 








0054 


97F2 


POP 


R2, 0R15 




0056 


5F00 


CALL 


DELETE_SEG 




0058 


0000V 








00 5A 


5E08 


Case 


#MA5S_SNOWN_CALL 


THEN 


005C 


010C ' 








005E 


0B02 








0060 


0005 








0062 


5E0E 








0064 


0070' 








0066 


97F2 


POP 


R2, (?R15 




0068 


5F00 


CALL 


MAKE_KNOVN 




006A 


0000'* 








006C 


5E08 


CASE 


#READ_CALL THEN 




006E 


010C ' 








0070 


0E02 








0072 


0006 








0074 


5E0E 








0076 


0082' 








0078 


97F2 


POP 


R2, 0R15 




007A 


5F00 


CALL 


read 




007C 


0000V 








007E 


5E08 


CASE 


i*SM_SWAP_lN_CALL 


then 


0080 


010C ' 








0082 


0E02 








0084 


0007 








0086 


5E0E 








0088 


0094' 








008A 


97F2 


POP 


R2, GR15 




008C 


5F00 


Call 


SM_SWAP_IN 




00SS 


0000V 








0090 


5E08 


CASE 


#SM_S’rfAP_OUT_CALL 


THE 


0092 


010C ' 








0094 


0E02 








0096 


0008 








0098 


5E0E 








009A 


00A6' 








009C 


97F2 


POP 


?.2, C“Rlb 




009E 


5F00 


CALL 


S^^_SWAP_OUT 




00A0 


0000V 








00A2 


5E08 


CASE 


^TERriINATE_CALL 


THEN 


00A4 


010C' 








00A6 


0B02 











0009 




04JAA 


5S0E 




00AC 


00B8 ' 




00AE 


97F2 


POP R2, ORlb 


00B0 


5F00 


CALL TERI^INATE 


00B;i 


0000V 




00B4 


5E08 


CASE ^TICKBT_CALL TPEN 


00B6 


010C ' 




00B8 


0E02 




00BA 


00 0A 




003C 


5E0E 




00BE 


00CA' 




00C0 


97F2 


POP R2, 0R15 


00C2 


5F00 


CALL TICKET 


00C4 


0000V 




00C6 


5E08 


CASE #WRITE_CALL THEN 


00C8 


010C' 




00CA 


0B02 




00CC 


000B 




00CE 


5E0E 




00D0 


00DC ' 




00D2 


97F2 


POP R2, 0Rlb 


00D4 


5F00 


CALL WRITE 


00D6 


0FC8 




00D8 


5E08 


CASE ?jWRIT£LN_CALL THEN 


00 DA 


010C ' 




00DC 


0B02 




00 DE 


000C 




00E0 


5E0E 




00E2 


00EE' 




00E4 




POP R2, 0R15 


00E6 


5F00 


CALL WRITELN 


00E8 


0FC0 




00EA 


5E08 


CASE *CRLF_CALL THEN 


00EC 


010C ' 




00EE 


0B02 




0010 


000D 




00F2 


5E0E 




00F4 


0100' 




00F6 


97F2 


POP P2, ORlb 


00FS 


5F00 


CALL CELF 


00FA 


0FD4 




00FC 


5E08 


ELSE 'INVALID KERNEL INVOCATION! 


00FE 


010C ' 


! RETURN TO f^ONITOR ! 

! NOTE; THIS RETURN TO MONITOR IS 






FOR STUB USE ONLY. AN INVALID 
KERNEL INVOCATION WOULD NORMALLY 
RETURN TO USER. ! 


0100 


7601 


LDA Rl, $ 


0102 


0100' 
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01k;4 210Z 
0106 0EAD 
0108 5F00 
010A A902 



010C 93F1 

010E 34F1 
0110 0004 



0112 1C19 
0114 010F 



0116 2DF1 

0118 33F1 
011A 0004 

011C 97F1 

011E 33F1 
0120 001E 



LD H0, #INVALID_KERNEL_ENTRY 
CALL ^'0NIT01^ 



FI 

! SA7E REGISTERS ON KERNEL STACK ! 
! SAVE R1 ! 

RUSK GR15, R1 

! GST ADDRESS OF REGISTER BLOCK ! 
LDA Rl, R15(#4) 

! SAVE REGISTERS IN REGISTER BLOCK 
ON KERNEL STACK. ! 

LDM ORl, Rl, #16 

! RESTORE Rl BUT MAINTAIN ADDRESS 
OF REGISTER BLOCK ! 

EX Rl, OR15 

! SAVE Rl ON STACK ! 

LD R15(#4), Rl 

! RESTORE REGISTER BLOCK ADDRESS ! 
POP Rl, 9Rib 

! SAVE VALID EXIT SP VALUE ! 

LD R15(#30), Rl 



! EXIT KERNEL BY MEANS OF EARD’ifARI 
PREEMPT HANDLER ! 

0122 5E08 JP KERNEL EXIT 
0124 0000’i' 

0126 END GATS_KEEPER_MAIN 

END KERNEL GATE KEEPER 
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SOURCE STATEl^ENT 



Z6000ASn 2.£<-d 
LOG OSJ CODE 



USER_GATE MODULE 

$LISTON $TTY 



CONSTANT 

ADVANCE_CALL 

AWAIT CALL 

CREATE_SEG_CALL 

DELETS_S£G_CALL 

MA5E_KN0WN_CALL 

READ_CALL 

SM_SWAP_IN CALL 

SM SWAP_OUT_CALL 

TERMINATE_CALL 

TICKET_CALL 

WRITE_CALL 

WRITELN_CALL 

CRLF CALL 



1 

4 

b 

6 

7 

b 

9 

10 
11 
12 
15 



GLOBAL 

^SECTION USER_GATE_PROC 



0000 



0000 7F01 
0002 9E08 
0004 



ADVANCE PROCEDURE 

^ PARAMETERS: 

Rl: SEGMENT ft 

^ R2:INSTANCE (ENTRY#^^ 

jp jp V JJS V V ?! 3? S)t V sp S? V S? 5is V W V V 

- RETURNS: - 

=5= R0:SUCCESS CODE 

^! V5??t3P3p3P?£?!3pS?3P5P?!3psp?t3P3pSp?!?!3P!P I 

SNTR^ 

SC #ADVANCE_CALL 
RET 

END ADVANCE 



0004 AWAIT PROCEDURE 



V 


PARAMETERS: 






Rl: SEGMENT # 






R2: INSTANCE 






RR4:SPECIFIED VALUE 




3JC ^iC 3;c 3^ 5^5JC 3JC 39 c 5JC 3JC 3JC 5^ 3^ : 5 c 5^ 5^ S?5jC 5^c age 34C 


3SC 


RETURNS : 




a? 


R0:SUCCESS CODE 





ENTRY 
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#AWAIT CALL 



e(?e)4 

0005 

0008 

0008 



0008 
000 A 
000 C 

000C 



000C 

000E 

0010 

0010 



0010 

0012 

0014 



7F02 SC 

9E08 RET 

END AWAIT 



7F03 

9E08 



create_seg procedure 

f ^ V V V ^ 5,65^ 5^5 

=«' PARAMETERS : -i* 

'•i' Rl:MENTOR_SEG_NO 

R2:ENTRT_N0 >•' 

- R3:SIZ£ ’i' 

- RR4: CLASS 

^ W W W V ^ V >■< W V W ^ 

=5' RETURNS: ^ 

R0:SUCCESS CODE - 

W ^ S|C 5,2 i|S sjc 3? jjC ^ 2;; sjs 3jf s;«2^ 2 ^ f 

ENTRY 

SC #CREATE_SEG_CALL 
RET 

END CREATE SEG 



7F04 

9Eee 



DELETE_SEG PROCEDURE 

I ffi 2|2 5^«2,» 2^^ 5,2 ^5|S 3{« ^ 2,* S^2|^ ^ 5|S ^25^ 5,2 5^2^ 5^2|C 5^ 

PARAMETERS : 

- Pl:MENTOR_SEG_NO 
V R2:ENTRY_N0 - 

5? iff V 5r W W V iff !1« V :?e ;?e V Tt V V 5? 

=" RETURNS ; 

’•= R0: sue CESS CODE - 

:;:9;;(9;cntiffiff iffiffiffiffiff iff’riff’ffiffiff^^iff iff^>ff j 

ENTRY 

SC #DELETE_SEG_CALL 
RET 

END DELETE SEG 



MAKE_KNOWN PROCEDURE 





PARAMETERS : 


ns 




RlrMENTOR SEG NO 


ns 




R2: ENTRY NO 


ns 




R3:ACCESS DESIRED 


ns 


2^2 2 j |2 2 | 22|2 ^ 2*,2 5^2 2 ^ 2 J|C 2 ^ 2^2 2,2 2,2 2^2 2 ^ 2,2 ^ 2 5 j |2 2,2 2 , 22 ^ J 


ns 5 |S 


3 C « 


RETURNS : 


n « 




R0:SUCCESS CODE 


ns 




RlrSEGMENT # 


ns 


ns 


R2: ACCESS ALLOWED 


ns 



3^:;::(Ci73;c9^!;c:is:tc:;c7:;:Viffs>t>ff:ff>>i:ff’r’ff’r’ff’r t 

ENTRY 

7E05 SC #MAKE_KNOWN_CALL 

9E08 RET 

END MAKE KNOWN 
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0^14 



0014 7F0t> 
0016 9E08 

0015 



READ PROCEDURE 

9 





PARAMETERS: 


2,5 




Rl.-SEGMENT # 




3i' 


^2: INSTANCE 


2r 


2*.' 5, 


ifZ 2|* ifi if 2|S «|* 3g« ifi Sj^ ^C«i« 


2i* 2,5 3;5 




RETURNS : 


2? 


3?: 


R0:SUCCESS CODE 


3i« 


2.: 


RR4 :EVENTCOUNT 





ENTRY 

SC ;fREAD_CALL 
RET 

END READ 



0018 



0018 7F0V 
001A 9E08 
001C 

001 C 



001C 7F08 
001E 9S08 
0020 



0020 



SM_SWAP_IN PROCEDURE 

»•' PARAMETERS; ^ 

Rl; SEGMENT ff ^ 

^ RETURNS; 

R0:SUCCSSS CODE - 

ENTRY 

SC #SM_SWAP IN_CAIL 

RET 

END SM_SWAP_IN 
SM_SWAP_OUT PROCEDURE 

^ PARAMETERS: 

- Rl; SEGMENT ^ - 

^ RETURNS : 

?0; SUCCESS CODE - 

ENTRY 

SC ;#SM_SWAP_OUT_CALL 

RET 

END SM_SWAP_OUT 

TERMINATE PROCEDURE 

^ PARAMETERS: =!' 

*•' Rl: SEGMENT tf - 

RETURNS; 

- P0: sue CESS CODE - 

3^3|»;C3i:3gC3ie3ie3^3;c)?:;c:tC3gc>,C3;C3^>jC3iC93iC f 

ENTRY 
SC 



0020 7F09 



#terminate call 



01322 

0024 

0024 



0024 
0026 
0023 

0025 

0023 

002A 

002C 

002C 

002C 

002E 

0060 

0030 

0030 

0032 

0034 



9E0S T’ET’ 

END TERMINATE 

TICKET PROCEDURE 

- PARAMETERS: - 

Ri: SEGMENT ^ 

V ^ ijt 5,5 3^5 Si* J|i Jgt sp S,C ^ 5JJ 5iS 5|i i,c 5|55,5 5^ 5^5 5,: 

^ RETURNS: 

R0:SUCCESS CODE =5* 

RR4:TICKET VALUE 

5;c5^:;5 5^5;c^:^agc5p5ic5^:^5;ca;c5^:;5 3is5ic5^5^5)c5;55^5,5 ? 

ENTRY 

7P0A SC #TICKET_CALL 

9 £03 RET 

END TICKET 

VRITE PROCEDURE 

ENTRY 

7E0B SC #WRITE_CAIL 

9E03 RET 

END WRITE 

WRITELN PROCEDURE 

ENTRY 

7F0C SC #WRITELN_CALL 

9E03 RET 

END WRITELN 

CRLF PROCEDURE 

ENTRY 

7F0D SC #CRLF_CALL 

9E08 RET 

END CRLF 



176 



APPENDIX E - BOOTSTRAP LOADER LISTINGS 



Z8000ASM H.02 
LOG OBJ CODE 



STMT SOURCE STATEMENT 
BOOTSTRAP LOADER MODULE 



SLISTON STTT 
CONSTANT 



TYPE 



! system parameters j 



NR CPU 


= 2 


NR VP 


= NR CPU’*‘4 


NR AVAIL VP 


= NR CPU ^2 


MAX DBR NR 


= 10 


STACK SEG 


= 1 


STACK SEG SIZE 


= %100 


STACK BLOCK 


= STACK SEG SIZE/255 


I ,jc 7 OFFSETS IN STACK SEG ! 


STACK base 


= STACK SEG SIZE-%10 


STATUS REG BLOCK 


= STACK SEG SIZE-%10 


INTERRUPT FRAME 


= stack base-4 


INTERRUPT REG 


= INTERRUPT FRAME-34 


N S P 


= INT£RRUPT"REG-2 


F C ¥ 


= STACK SEG SIZE-%E 


vwvw SYSTEM CONSTANTS » 


ON 


= %FFFF 


OFF 


= 0 


READY 


= 1 


NIL 


= %FFFF 


INVALID 


= %EEEE 


KERNEL FCW 


= %5000 


AVAILABLE 


= 0 


ALLOCATED 


= %FF 


SC OFFSET 


= 12 



MESSAGE 
ADDRESS 
MM_VP_ID 
VP INDEX 
MSS INDEX 



ARRAY 

WORD 

WORD 



115 BYTE] 



INTEGER 

INTEGER 
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MSG TABLK RECORD 
L MSG 
SENDER 
NEXT_MSG 
FILLER 



MESSAGE 
7P_INDEX 
MS G_ INDEX 
ARRAY [ 6 , 



J 



WORD] 



^P_TA3LE RECORD 

[ DBR ADDRESS 

PR I WORE 

STATE WORD 



IDLE FLAG WORD 

PREEMPT 'WORD 

PHYS_PROCESSOR WORD 
NEXT_READY_VP 7P_INDEX 
MSG LIST MSG_INDEX 

EXT^ID WORD 

FILL£R_1 ARRAY . 



WOHDJ 



EXTERNAL 

GET_D£R ADDR PROCEDURE 

CREATE STACK PROCEDURE 



LIST_INSERT PROCEDURE 

ALLOCATE_MMU PROCEDURE 

UPDATE_MMU_IMAGE PROCEDURE 
MM_ALLOCATE PROCEDURE 

MM_ENTRT LABEL 

IDLE ENTRY LABEL 



PREEMPT_RET LABEL 

BOOTSTRAP ENTRY LABEL 



GATE_KEEPER_ENTRY LABEL 

NEXT_BLOCK WORD 

MM CPU_TBL ARRAY [NR CPU MM_VP IDJ 



VPT RECORD 

[ LOCK WORD 

RUNNING_LIST ARRAY [NR_CPU WORDJ 
READY_LIST ARRAY [NR_CPU WORDJ 
FREE_LIST MSG INDlX 

VIRT_INT_VEC ARRAY [1, ADDRESSJ 
FILLER_2 WORD 

VP ARRAY [NR_VP, VP_TABLEJ 

MSG_0 ARRAY [NR_VP, MSG_TABLEJ 
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0 fc }00 

0002 



fiXT_VP_LIST ARRAY [NR_AVAIL VP WORDJ 
NEXT_AVAIL_MMU ARRAY IMAX_DER][nR EYTEJ 

PHDS RECORD 

[PHYS CPU ID WORD 

iog_cpu_Id integer 

VP_NR WORD 

IDLS_VP VP_INDEX] 



INTERNAL 

^SECTION L0ADER_DATA 

! NOTE: THESE DECLARATIONS WILL NOT WORK 
IN A TRUE MULTIPROCESSOR ENVIRONMENT AS 

they are subject to a "call." they must 

BE DECLARED AS A SHARED GLOBAL DATABASE 
WITH "RACE" PROTECTION (E.G., LOCK). ! 

NEXT AVAIL_VP INTEGER 
NEXT"EXT VP INTEGER 
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li-t " 



0000 



0000 

0002 

0004 



0006 
0008 
000 A 



000C 

000E 

0010 

0012 

0014 

0016 

0018 

001A 

001C 



001E 



0020 

0022 

0024 

0026 



SSECTICN LOADEH INT 
INTERNAL 

BOOTS THAF PROCEDURE 

’i' creates kernel processes and 

’i' INITIALIZES KERNEL DATABASES.-' 
^ INCLUDES INITIALIZATION OF 
’i' VIRTUAL PROCESSOR TABLE, "• 

- EXTERNAL 7P LIST, AND 

images. ALLOCATES MMU IMAGE '*!' 
AND CREATES KERNEL DOMAIN ’i' 
^ STACK FOR KERNEL PROCESSES. •“ 

^jcsje^tcjiesy^ssf jjsws!tJ!tW5!S5?’P^tS!'»)t=(t=p5i'spJi«’PW^V=?3^ » 



ENTRY 

! INITIALIZE PRDS AND MMU POINTER ! 

! NOTE: TEE FOLLOWING CONSTANTS ARE 
ONLY TO BE INITIALIZED ONCE. THIS 
WILL OCCUR DURING SISTEM INITIALIZATION! 
4E05 LD PRDS.?HYS_CPU_IL, #‘?FEEE 

0000’i' 

FFEE 

! NOTE: LOGICAL CPU NUMBERS ARE ASSIGNED 
IN INCREMENTS OF 2 TO FACILITATE INDEXING 
(OFFSETS) INTO LISTS SUBSCRIPTED BY 
LOGICAL CPU NUMBER. ! 



4D05 


LD 


PRDS.LOG_CFU_ID, #2 


0002’!' 

0002 


1 


SPECIFY NUMBER OF VIRTUAL PROCESSORS 






ASSOCIATED WITH PHYSICAL CPU. ! 


4D05 


LD 


PRDS.VP_NR, #2 


0004’!' 

0002 

4D08 


CLR 


NEXT_BLOCK 


0000S? 

4D08 


CLR 


NSXT_AVAIL_7P 


0000' 

4D08 


CLR 


NEXT_EXT_VP 


0002' 







I ESTABLISH GATE KEEPER AS SYSTEM CALL 
TRAP HANDLER ! 

! GET BASE OF PROGRAM STATUS AREA ! 

7D15 LDCTL R1 , PSAP 

! ADD system CALL OFFSET TO PSA EASE ADDR ! 
0101 ADD Rl, #SC_OFFS£T 

000C 

I STORE KERNEL FCW IN PSA ! 

0D15 LD ORl, #KSRNEL_FCW 

5000 
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0028 

002A 

002C 

002E 



0030 

0032 

0034 

0036 

0038 
^ 003A 

003C 
003E 
0040 
0042 
0044 



0046 

0048 



004A 

004C 



004E 

0050 

0052 

0054 

0056 

0058 

005A 

005C 

005E 

0060 

0062 

0064 

0066 

0068 

006A 



! STORE ADDRESS 0? 5ATE SESPER IN PROGRAM 





STATUS 


AREA AS SYSTEM TRAP HANDLER ! 


A911 


INC 


R1 , #2 


0D15 


LD 


GRl, #GATS_KSEPER_ENTRr 


0000’!' 

8D18 


CLP 


HI ! NEXT_AVAIL_MMU INDEX ! 




! INITIALIZE ALL MMU IMAGES AS AVAILABLE 




SET_MMU_MAP 


« 


4C15 


DO 

LDF 


NEXT_AVAIL_MMU(R1) , #AVAILA£LE 


0000’!' 

0000 

A910 


INC 


Rl, #1 




! CHECK FOR END OF TADLE ! 


0E01 


CP 


Rl, ffMAX_DBR_NR 


000A 

5E0E 


IF EO 


THEN EXIT from SET_MMU_MAP FI 


0044' 

5E08 

0046' 

E8F5 


OD 






! CREATE 


MEMORI MANAGER PROCESS ! 


2103 


LD 


R3, #STACK BLOCK 


0001 


! ALLOCATE AND INITIALIZE KERNEL 




DOMAIN 


STACK SEGMENT ! 


5P00 


CALL 


MM_ALLOCATE ! R3 : # OF SLOCKS 


0000’!' 






A121 


LD 


RETURNS 

R2: START ACER ' 

Rl, R2 


2103 


LD 


R3, #KERNEL_FCW 


5000 

7604 


LDA 


R4, MM_ENTRY 


0000*!* 

6105 


LD 


R5, %FFFF !NSP! 


FFFF 

7606 


LDA 


R6, PREEMPT_RET 


0000^ 

93F1 


PUSH 


GR15, Rl !SAVE STACK ADIR! 


030F 


SUB 


R15, #8 


0008 

1CF9 


LDM 


GR15, R3, ?i4 


0303 

A1F0 


LD 


R0, R15 




! NOTE: 


ARGLIST FOR CREATE STACK INCLUDE 




KERNEL 


_FCW, INITIAL IC, NSP, AND INITI 
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RETURN POINT. ! 



008C 


5F00 


CALL 


CREATE_STACK ! (R0: ARGUMENT PTR 


006E 


0000’!' 




Rl: TOP OF STACK 
R2-R14: INITIAL 
REG. STATES ! 


0070 


010F 


ADD 


Rib, «8 lOVERLAY ARGUMENTS! 


0072 


0008 










! ALLOCATE MMU IMAGE ! 


0074 


5F00 


CALL 


ALLOC ATS_MMU ! RETURNS: 


0076 


0000’i' 




(R0: DBR #) ! 


0078 


2101 


LD 


Rl, #STACK_SSG ! SEGMENT NO. ! 


007A 


0001 






007C 


97F2 


POP 


R2, 0R15 !GET STACK ADDR! 


007E 


2103 


LD 


R3, f?0 ! WRITE attribute ! 


0080 


0000 










! SPECIFY NUMBER OF BLOCKS. COUNT STARTS 






FROM 


ZERO. (I.E. ,i SLOCK=0, 2=1, ETC.)! 


0082 


2104 


LD 


R4, #stack_biock-i 


0084 


0000 


! SAVE 


DER # ! 


0086 


93F0 


PUSH 


0R15, R0 



0088 5F00 
008A 0000» 



008C 97E0 



! CREATE t^MU ENTRY FOR MM STACK SEGMENT ! 
CALL UPDATE MMU IMAGE !(R0: DSR « 



! RESTORE DER ff \ 
POP R0, 0R15 



Ri: SEGMENT 
Rii: SEG ADDRESS 
R3: SEG ATTRIRUTES 
R4: SEG LIMITS) ! 



! GET ADDRESS OF MMU IMAGE ! 

008S 5F00 CALL GET_D£R ADDR ! (R0: DER rt) 

0090 OOOO’i' 

RETURNS : 

(Kl; DER ADDRESS) ! 
! PREPARE VP TABLE ENTRIES FOR MM ! 



0092 


2102 


LD 


R2, #2 


! PRIORITY I 


0094 


0002 








0096 


2105 


LD 


R5, #OFF 


! PREEMPT ! 


0098 


0000 








009 A 


2106 


LD 


R6, #OFF 


! KERNEL PROCESS 


009C 


0000 












! UPDATE 


VPT ! 




009E 


5F00 


CALL 


UPDATE_7P, 


_TABLS !(Rl: DBR 


00A0 


01CA' 









RH: PRIORITY 
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Rb: PESEr^PT FLAG 
R6: EXT_VP FLAG) 
RETURNS : 

R9: VP_ID ! 

! INITIALIZE MM_CPU_T£L IN DISTRIFUTED MEriORY 
MANAGER WITH VP ID OF MM PROCESS J 
! GET LOGICAL CPU # ! 



00A2 


bl0A 


LD R10, PRDS .LOG CPU ID 


00A4 


0002’!' 






00A6 


6FA9 


LD 


MM_CPU_TBL(R10) , R9 


00A8 


0000V 


! create 


IDLE PROCESS ! 


00AA 


2103 


LD 


R3, #STACK_BIOCK 


00AC 


0001 






00AB 


5F00 


CALL 


MM_ALLOCATE !R3: OF BLOCKS 


0050 


0000’i' 












RETURNS 

R2: START ADDR! 


00R2 


A121 


LD 


R1 , R2 


00B4 


2103 


LD 


R3, #EERNSL_FCW 


00E6 


5000 






00R8 


7604 


LDA 


R4, IDLS_SNTRY 


00SA 


0000V 






00BC 


2105 


LD 


R5, #%FFFF !NSP! 


00BE 


FFFF 






00C0 


7606 


LDA 


R6, PRESMPT_RET 


00C2 


0000’!' 






00C4 


93F1 


PUSH 


OR 15, R1 '.SAVE STACK ADDR! 


00C6 


030F 


SUB 


R15, #8 


00C8 


0008 






00CA 


1CF9 


LDM 


0R15, R3, #4 


00CC 


0303 






00CE 


A1F0 


LD 


R0, R15 






! INITIALIZE IDLE STACK VALUES ! 


00D0 


5F00 


CALL 


CREATE_STACK ! (R0; ARGUMENT FT^^ 


00D2 


0000=^ 












R1 : TOP 01 STACK 
R2-R14: INITIAL 
REG. STATES ' 


00D4 


010F 


ADD 


R15, #8 'OVERLAY ARGUMENTS! 


00D6 


0008 










? ALLOCATE MMU IMAGE FOR IDLE PROCESS ! 


00D8 


5F00 


CALL 


ALLOCATE_MMU ! RETURNS R0:D3R !f 


00DA 


0000V 










! PREPARE 


IDLE PROCESS MMU ENTRIES ! 


00DC 


2101 


LD 


Rl, #STACK_SEG ! SEG # ! 


00DE 


0001 






00E0 


97F2 


POP 


R2, 0R15 !GET STACK ADDR! 
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i A 1 



00E2 


2103 


LD 


R3, #0 


! a’RITE attribute 


00E4 


0000 








00E6 


2104 


LD 


R4, #STACK_BLOCK 


-1 ! BLOCK LI'^ITS 


00E8 


0000 












! SAVE DRR ^ 1 




00EA 


93F0 


PUSH 


GR15, R0 








! create 


IMAGE ENTR"^ ! 




00EC 


5F00 


CALL 


DPDATEj'1MU_lMAGE 


! (31 : SEGMENT ti 


00EE 


0000=^ 






R2: SEG ADDRESS 
R3: SEG ATTRIBUT 
R4: SEG LIMITS ) 






! RESTORE 


DER # ! 




00F0 


97F0 


POP 


R0, yR15 








! GET r^MU 


ADDRESS ! 




00F2 


5F00 


CALL 


GET_DBR_ADDR ! 


(R0: DPR ft) 


00F4 


0000*^ 






RETURNS 

(Rl: DPR ADDRESS) 






! PREPARE 


VPT ENTRIES FOR 


IDLE PROCESS ! 


00F6 


2102 


LD 


R2, #0 


! PRIORITY ! 


00F8 


0000 








00FA 


2105 


LD 


R5, #?OFF 


! PREEMPT ! 


00FC 


0000 








00FE 


2106 


ID 


R6, ft 077 


! KERNEL PROC ! 


0100 


0000 


! CREATE 


VPT ENTRIES ! 




0102 


5F00 


CALL 


update_vp_table 


!(Rl: DSR 


0104 


01CA' 









0106 6F09 
0108 0006' 



R2: PRICP.ITI 
R4: lELfi.ILAG 
R5: PREE^'FT 
R6: EXT_VP FLaG^ 
RETURNS : 

R9; VP ID ! 

! ENTER VP ID OF IDLE PROCESS IN FRDS ! 

LD PRDS.IDLE VP, R9 







! INITIALIZE 


IDLE VP'S ! 




010A 

010C 


2102 

0001 


LD 


R2, 


#1 


! PRIORITY ! 


010E 

0110 


2105 

FFFF 


LD 


Rb, 


#ON 


! PREEMPT ! 


0112 

0114 


2106 

FFFF 


LD 


R5, 


#ON 


' NON-KERNEL 


0116 


6100 


LD 


R0 , 


PRDS .VP_NR 




0118 


0004 


! INITIALIZE 


VP VALUES ! 





134 







DO 




011A 


5F00 


CALL 


UPDATE_VP_TA3LS !(R1: EBR 


011C 


01CA' 




R2: PP.IORITI 
R4: IDLE FLAG 
R5: PREEMPT 
H6: EXT VP FLAG) 
RETURNS: 

R9: VP ID ! 


011£ 


A£00 


DEC 


R0, #1 


0120 


0B00 


CP 


R0, 


0122 


0000 






0124 


5E0S 


IF EC 


’ALL VP'S INITIALIZED! THEN 


0126 


012C' 






0128 


5E08 


EXI 


rp 

i. 


012A 


012E' 


FI 




012C 


E8F6 


OD 








! INITILIZE VPT HEADER ! 

! GET LOGICAL CPU NUMBER ! 


012E 


6102 


LD 


R2, PRDS .LOG_CPU_ID 


0130 


0002==* 






0132 


4D05 


LD 


VPT. LOCK, JiOFF 


0134 


0000>i‘ 






0136 


0000 






0138 


4D25 


LD 


VPT.RUNNING_LIST(R2) , #NIL 


013A 


0002’!' 






013C 


FFFF 






013E 


4D25 


LB 


VPT.HEADY_LIST(R2) , ??NIL 


0140 


0006’!' 






0142 


FFFF 






0144 


4D08 


CLH 


VPT.FRSE_LIST ’HEAD CF MSG LIST! 


0146 


000A=^ 








1 


THREAD VP 


'S BY PRIORITY AND SET STATES TO READY 


0148 


6D28 


CLR 


R2 ISTART WITH VP #1! 






THREAD: 








DO 




014 A 


610D 


LD 


R13, PRDS .LOG_CPU_ID 


014C 


0002’!' 






014E 


76D3 


LDA 


R3,VPT.READT_LIST(R13) 


0150 


0006=* 






0152 


7604 


LDA 


R4, VPT.VP. NEXT_READY_VP 


0154 


001C’!' 






0156 


7605 


LDA 


R5,VFT.VP.PRI 


0158 


0012’" 






015A 


7606 


LDA 


R6, VPT. VP. STATE 


015C 


0014’" 






015E 


2107 


LD 


R7 ,#READY 
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0160 0001 



0162 

0164 

0166 



0166 

016A 

016C 

016E 

0170 

0172 

0174 

0176 

0178 

017a 



017C 



017E 

0180 

0162 

0184 



0186 

0188 

018A 

018C 

018E 

0190 

0192 

0194 



! SAVE OBJ ID ! 

93E2 PUSH 0R15. R2 

5E00 CALL LIST_1NSSRT !R2: OBJ ID 

0000V 



R3: 


LIST HEAD 


PTR ADDR 


R4: 


NEXT OBJ 


PTR 


R5 ; 


PRIORITY_ 


PTR 


R6 : 


STATE PTP. 




R7: 


STATE ! 





! RESTORE OBJ ID ! 

97F2 POP R2, 0R15 

0102 ADD R2, #SIZEOE VP_TABL£ 

0020 

0E02 CP P2, ??(NR_VP - (SIZEOP V?_TABLE)) 

0100 

5E0E IF EO TEEN EXIT PROM THREAD FI 

017A' 

5E08 
017C ' 

E8E7 OD 

! INITIALIZE VP MESSAGE LIST ! 

! NOTE; ONLY THE THREAD FOR THE MESSAGE 
LIST NEED BE CREATED AS ALL MESSAGES 
ARE INITIALLY AVAILABLE FOR USI. THE 
INITIAL MESSAGE VALUES WERE CREATED 
FOR CLARITY ONLY TO SHOW THAT THE 
MESSAGES HAVE NO USABLE INITIAL VALUE! 
8D1B CLR R1 

MSG LST_INIT; 

"l NOTE: R1 REPRESENTS CURRENT ENTRY IN 

MSG LIST, R2 REPRESENTS CURRENT POSITION 
IN MSG_LIST entry, AND R3 REPRESENTS 
NEXT ENTRY IN MSG LIST. ! 

DO 

A112 LD R2, R1 

A 123 LD R3, R2 

0103 ADD R3, #SIZSOF MESSAGE 

0010 

FILL_MSG; 

DO 

4D25 LD VPT.MSG C.MSG(R2), #INVALID 

0110>i‘ 

EEEE 

A921 INC R2, #2 

8B32 CP R2, R3 

5E0E IF EO THEN EXIT FROM FILL_MSG FI 

0198 ' 

5E08 



0198 
019A 
019C 
019S 
01A0 
01A2 
01A4 
01A6 
01 AS 

01AA 

01AC 

01AE 

01B0 

01B2 

01S4 

01B6 

eiue 

01BA 

01BC 

01BE 

01C0 



01C2 

01C4 



01C6 

01C8 

01CA 



019A ' 
E6F5 


OD 




4Dlb 


LD 


7PT.MSG_0.SENDER(R1) , #NIL 


OlBO’i' 






FFPF 

A112 


LD 


R2, R1 


0101 


ADD 


Hi, ffSIZEOF MSG_TABLE 


0020 

0B01 


CP 


Rl, #SIZEOF MSG_TABLE’^NR_VP 


0100 

5E0E 


IF EC 
THEN 




01BC ' 
4D25 


LD 


VPT.MSG_0.NSXT_^SG(R2) , #NII 


0122>^ 

FFFF 

5E08 


EXIT 


FROM MSG_LST_INIT 


01C2' 

5E08 


ELSE 




0100' 

6F21 


LD 


VPT.MSG_0.NEXT_MSG(R2) , Rl 


0122=^ 






E8DE 


FI 

OD 






! GST LOGICAL CPU # FOR USE 




B^ ITC 


GETWORE . ! 


510D 


LD 


R13, PRDS.LOG CPU ID 


0002=^ 


! BOOTSTRAP COMPLETE ! 




! START 


S"^STEM EXECUTION AT PREEMPT ENTRY 




! POINT 


IN ITC GETVORK PROCEDURE ! 


5E08 


JP 


BOOTSTRAP ENTRY 


0000Sr 







END BOOTSTRAP 
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m 




01CA UPDATE VP TAELS PHOCEDUHE 

I a;t:^3jc3;sa;c;4c:;t:t:3;{:?:;?3!ca;<a^3iti!ca;«3jc;p;?ajs>iC3;s3SCa;c3;s3;«j;c5;«;ff:5sa^ 



?je 


INITIALIZES VPT ENTRIES 




^ # 1 % ^ 1 % ^ ^ ^ 


^ »,% - 


,• »,% 




REGISTER USE; 




ajt 




PARAMETERS ; 




3^ 




Rl: DBR ADDRESS 




*<5 


ajc 


R2; PRIORITY 




V 


3;« 


R5; PREEMPT FLAG 






V 


R8; EXTERNAL VP 


FLAG 




5? 


RETURNS; 








R9; ASSIGNED VP 


ID 


a? 




LOCAL VARIABLES; 




V 


a;* 


R7; LOGICAL CPU 


tt 


3? 




R8; EXT VP LIST 


OFFSET 


'iC 


a? 


R9; VPT OFFSET 




a? 



^a;sa;s3;c3jsajc3i«a;ssiff59cs?3;sa;sv3^5is3;s3;5a;ca;sa;53;5a;s3;s3;sa;s3;s3js3^a;s3;s3;s f 



ENTRY 

! GST OFFSET IN VPT FOR NEXT ENTRI ! 



eiCA 


6109 


LD 


R9, NEXT_AVAIL_VP 


01CC 


0000 ' 






01CE 


6F91 


LD 


V?T.VP.DBR(R9) , Rl 


01D0 


0010^^ 






01D2 


6F92 


LD 


VPT.VP'.PRI (R9) , R2 


01D4 


0012^ 






01D6 


6F96 


LD 


VPT.VP.IDLE_FLAG(R9) . R6 


01D8 


0016»^ 






01DA 


6F95 


LD 


VPT. VP. PREEMPT (R9) , R5 


01DC 


0018» 






01DE 


6107 


LD 


R7, PRDS .LCG_CPU_ID 


01E0 


0002’!' 






01E2 


6F97 


LD 


VPT.VP.PEYS_PROCESSOR(R9U R7 


01E4 


001A’!' 






01E6 


4D95 


LD 


VPT.VP.NEXT_P.EADT_V?(R9) , SNIL 


01E8 


001C’" 






01EA 


FFFF 






01SC 


4D95 


LD 


VPT.VP.MSG_LIST(R9) , #N II 


eiEE 


001E’" 






01F0 


FFFF 


! CHECK 


EXTERNAL VP FLAG 1 


01F2 


0B06 


CP 


R6, #ON 


01F4 


FFFF 


IF EO 


! EXTERNAL VP! 


01F6 


6E0E 


TEEN 


! VP IS TC VISIBLE ! 


01F8 


0210' 






01FA 


6108 


LD 


R8, NEXT_EXT_VP 


01FC 


0002' 










! INSERT ENTRY IN EXTERNAL VP LIST ! 


01FE 


6F89 


LD 


EXT_VP_LIST(R8) , R9 
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0ki00 


0000>» 






0202 


6F98 


LD 


VPT.VP.EXT_ID(R9U R8 


0204 


0020=^ 






0205 


A981 


INC 


R8, #2 


0208 


6F08 


LD 


NSXT_EXT_?P, R8 


020A 


0002' 






020 C 


5E08 


ELSE !VP BOUND TO KERNEL PROCESS 


020E 


0216 ' 






0210 


4D05 


LD 


VPT. VP.SXT_ID, <:NIL 


0212 


0020’i‘ 






0214 


FFFF 


FI 




0216 


A19A 


LD 


R10, R9 


0218 


010A 


ADD 


R10, #SIZSOF ?P_TABLE 


021A 


0020 






021C 


6F0A 


LD 


NEXT_AVAIL_VP, R10 


021E 


0000' 






0220 


9E08 


RET 




0222 




END UPDATE 


7P TABLE 




END 


bootstrap' 


^loader 
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APPENDIX I - LIERARY FUNCTION LISTINGS 



Z6000ASM 

LOG CODE STMT SOURCE STATEMENT 



LIRRAR’^ function MODULE 



SLISTON $TTY 

CONSTANT 
KEP.NEL_FCW 
STACK_SSG_SIZE 
STACK_BASE 
STATUS_REG_ELOCK 
INTERRUPT FRAME 
INTEP.RUPT^REG 
N_S_P 
NIL 



= 'S5000 
= '^100 

= STACK SEG_SIZE-%10 
= STACK~SEG_SIZE-;S10 
= STACK_EASS-4 
= INTERRUPT_FRAME-24 
= INTERRUPT_REG-2 
= ^FFFF 
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^SECTION LIB_?POC 
GLOBAL 






LIST_1NSERT PROCEDURE 

INSERTS OBJECTS INTO A LIST 
BY ORDER OF PRIORITY AND SETS ^ 
’S' ITS STATS 

V >r W >i< >r V ^ V W a? V S|S V W V S|C ^ W 9 W W 



REGISTER USE: ^ 

PARAMETERS: 

’i' R2: OBJECT ID 

R3: HEAD_OF LIST PTR ADDR ^ 

« R4: NEXT_0BJ_PTR ADDR - 

^ R5: PRIORITY_PTR ADDR - 

R6: STATE_PTR ADDR ’=‘ 

R7: OBJECT STATS 
LOCAL VARIABLES: - 

R6: READ_OF_LIST PTR ’=' 

R9: NEXT_0BJ_PTR" 

- R10: CURRENT_OEJ PRIORITY ^ 

Rll: NEXT_OBJ PRIORITY ^ 



0000 2138 
0002 0E08 
0004 FFFF 
0006 5E0E 
0008 0018' 



ENTRY 

! GET FIRST OBJECT IN LIST ! 
LD R8, PR3 

CP R8, #NIL 

IF EO 'LIST IS EMPTY! THEN 



! PLACE OBJ AT HEAD OF LIST ! 



000A 


2F32 


LD 


0R3, R2 


000C 


7449 


LDA 


R9, R4(R2) 


000E 


0200 






0010 


0D95 


ID 


PR9. <iNII 


0012 


FFFF 






0014 


5E08 


ELSE 




0016 


005A' 










! compare OBJ PRI WITH LIST HEAD PRI ! 


0018 


715A 


LD 


R10, R5(R2) !OBJ PRI! 


001A 


0200 






001C 


715B 


LD 


Rll, R5(P8) !HSAD PRI! 


001E 


0800 






0020 


8BBA 


CP 


R10, Rll 

!OBJ PRI>HEaD PRI! TEEN 


0022 


5E02 


IF GT 


0024 


0030' 






0026 


2F32 


LD 


0R3, R2 !PUT AT FRONT! 


0028 


7348 


LD 


R4 ( R2 ) , R8 


002A 


0200 






002C 


5E08 


ELSE ! 


INSERT IN BODY OF LIST ! 
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00 2E 00 5A 



SEARCH LIST; 
DO" 



0030 


0B08 


CP 


R8, isNiL 


0032 


FEEF 






0034 


5E0E 


IE EC 


!END OF LIST! THEN 


0036 


003C ' 






0038 


5E08 


EXIT 


FROt^ SEARCH_LIST 


003A 


0052' 


FI 




003C 


715B 


LD 


Rll, R5(R8) 


003E 


0800 






0040 


8BBA 


CP 


R10, Rll 


0042 


5E02 


IF GT 


! CURRENT PRI^NEXT 


0044 


004A' 






0046 


5E08 


EXIT 


FROM SEARCfi_LIST 


0048 


0052' 


FI 








! GET 


NEXT OBJ ! 


004A 


A189 


LD 


R9, R6 


004C 


7148 


LD 


R8, R4(R9) 


004E 


0900 






0060 


E8EE 


OD ! 


END SEARCH_LIST ! 






! INSERT IN LIST ! 


0052 


7348 


LD 


R4(R2) , R8 


0054 


0200 






0056 


7342 


LD 


R4(R9), R2 


0058 


0900 


FI 








FI 








! SET OSJ 


ECT'S STATE ! 


005A 


7367 


LD 


R6(R2), R7 


005C 


0200 






005E 


9E08 


RET 





0050 



END LIST INSERT 



FP.I 



192 



0060 



CHEATii_STACK PROCEDURE 

f «l|« 3 |» dp dp dp dp djfC dp dj< d^« dp dp dpdjfC dp d^ d|d dp dp d^ dp d|* dp dp dp d |5 dp dp 

’i' INITIALIZES KERNEL STACK 

- segment fop. processes 

dp dpdp d^S d|C djC djC dJfS d^C dp dp d^« dpd|C dp dpdgC d|« dp d|S dp d|Cdp d|S dp d|S dp dp dp dp 

V 
3JC 
n« 

NO^ 

^ SPECIFIC INITIAL HEGlSTEfi ^ 

^ VALUES ARE SET , EXCEPT 

- (USER ID) FOR USER PRO- - 

^ CESSES.) ^ 

d;c d;c sgs die d^ dic d^c dic dp djC d;: d^ d;c d^ d^ d;c dic 3 (C d^ di« d^ di; d^ dic d^ d^ di« d^ d^ die 

- LOCAL VARIA5LES 



V 

V 



V 



V 



register USE: 

PARAMETERS : 

R0: ARGUMENT POINTER 
(INCLUCES:FCW,IC,NSP, AND 
RETURN POINT. SEE LOCAL 
VARIABLES BELOW.) 

Rl: TOP OF STACK 
R2-R14: INITIAL REGISTER 
STATES. (NOTE; IN DEMO, 



3? 


(FROM 


arguments stored ON 






STACK. ) 








R3 ; 


FCW 








R4: 


PROCESS 


ENTRY POINT (IC) 






R5: 


NSP 








R6: 


PREEMPT 


RETURN POINT 








ENTR”^ 



0060 93F0 


PUSH 


GR15, R0 !SAVB ARGUMENT PT? ! 


0062 ADF0 


EX 


R0, R15 !SAVE SP 1 


0064 341F 


LDA 


R15, R1(#INTSRRUPT_REG) 


0066 00CA 






0068 1CE9 


LDM 


ORlb, Rl, **16 ! INITIAL REG. VALU 


006A 010F 








! NOTE; 


ONLY REGISTERS R2-R14 MAT CONTAIN 




INITIALIZATION VALUES ! 


006C A10F 


ID 


R15, R0 'RESTORE SP! 


006E 97F0 


POP 


R0, 0R15 ! RESTORE ARGUMENT PTR! 


0070 AIFE 


ID 


R14, R15 !SAVE CALLER RETURN POIN' 


0072 A10F 


LD 


R15, R0 !GET ARGUMENT PTR! 


0074 ICFI 


LDM 


R3, 0R15, ^4 !LOAD ARGUMENTS! 


0076 0303 






0078 341F 


LDA 


Rib, R1(#INTERRUPT_FRAME) 


007A 00EC 






007C 1CF9 


LDM 


0Rlb, R3, #2 !INIT IRST FRAME! 


007E 0301 






0080 341F 


LDA 


R15, R1(»N_S_P) 


0082 00C8 






0084 2FF5 


LD 


0R15, R5 !SST NSP! 


0086 030F 


SUB 


R15, #2 
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LD 

LDA 



(3R15, R6 ! PREEMPT RET POINT! 
R8, Rl(i^STACK_BASE) 



0088 0002 
008A 2FE6 
008C 3413 
008E 00F0 

! INITIALIZE STATUS REGISTER ELOCK ! 



0090 


2100 


LL 


R0, #KSRNEL_FC'v 


0092 


5000 






0094 


1C89 


LDM 


ORS, R15, !SAVB SP FC'*' ! 


0096 


0F01 






0098 


AlEF 


LD 


R15, R14 I RESTORE RETURN POINT 


009A 


9E08 


RET 





009C END CREATE_STACK 

END LIBRARy FUNCTION 
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1 




appendh g - inner traffic contolier listings 



Zbee^ASM H.e2 

IOC OBJ CODE STMT SOURCE STATEMENT 

INNER_TRAF?IC_CONTROL MODULE 
^LISTON $TTY 



!--l. GETWORK; 

A. NORMAL ENTRY DOES NOT SAVE REGISTERS. 

( THIS IS A FUNCTION OF THi GATEKEEPER ). 

B. R14 IS AN INPUT PARAMETER TO GETWORK THAT 
SIMULATES INFO THAT WILL EVENTUALLY BE ON 
THE MMU HARDWARE. THIS REGISTER MUST EE 
ESTABLISHED AS A DBR BY ANY PROCEDURE 
INVOKING GETWCRK. 

C. THE PREEMPT INTERRUPT ENTRY HANDLER DOES 
NOT USE THE GATEKEEPER AND MUST PERFORM 
FUNCTIONS NORMALLY ACCOMPLISHED BY IT 
PRIOR TO NORMAL ENTRY AND EXIT. 

( SAVE/RESTORE: REGS, NSP; UNLOCK VPT, TEST INT) 



2. GENERAL: 

A. ALL VIOLATIONS OF VIRTUAL MACHINE INSTRUCTIONS 
APE CONSIDERED ERROR CONDITIONS AND WILL RETURN 
SYSTEM TO THE MONITOR WITH AN ERROR CODE IN R^ 
AND THE PC VALUE IN R1 . 

B. ITC PROCEDURES CALLING GETWORK PASS DPR 
(REGISTER R14) AND LOGICAL CPU NUMBER 
(REGISTER R13) AS INPUT PARAMETERS. 

(INCLUDES: SIGNAL, WAIT, SWAP VDrP. 

PHYS PREEMPT HANDLER, AND IDLE). ! 



CONSTANT 

T ^ V 3jfS ^ 5,C 

U L : = 

M_L_SM := 

M L ER := 

R~lIe := 

M_L_0 := 

SNA 

V~I“e := 

M U“ : = 



^ ERROR CODES » 

e ! UNAUTHORIZED LOCK ! 

1 ! MESSAGE LIST EMPTY ! 

2 ! MESSAGE LIST ERROR 1 

3 ! READY LIST EMPTY ! 

4 ! MESSAGE LIST OVERFLOW ! 

5 ! SWAP NOT ALLOWED ! 

6 ! VP INDEX ERROR ! 

7 ! MMU UNAVAILABLE ! 



NR_SDR 
NR_CPU 
NR VP 



SYSTEM PARAMETERS 

:= 64 !LONG WORDS! 
:= 2 

:= NR CPU’!'4 



NR AVAIL VP 



NR CPU’i‘2 
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MAX DBF. NR 


10 !PER 


CPU! 


STACK SEG := 


1 






PRDS SEG 


: = 


0 






STACK_SEG_SIZE := 


%100 






! OFFSETS IN 


STACK 


SEG 




STACK BASE := 


STACK 


SEG 


SIZE-%10 


STATUS REG BLOCK := 


STACK 


SEG 


“siZE-^10 


INTERRUPT FRAME := 


stack' 


BASE-4 


INTERRUPT REG := 


INTERRUPT 


_FEAME-34 


N S P 


: = 


interrupt 


R E G — 2 


F_C_W 


: = 


stack 


_SEG 


”SIZE-%E 


ON 


= %FFFF 








OFF 


= 0 








RUNNING 


= 0 








READY 


= 1 








WAITING 


= 2 








NIL 


= ^FFFF 








INVALID 


= ^EEEE 








MON ITOR 


:= XA900 




! H3UG ENTRY 


KERNEL FCW := ^5000 






AVAILABLE := 0 








ALLOCATED := %FF 









TYPS 

MESSAGE AREAY [16 £YTE] 

ADDRESS WORD 
VP_INDEX INTEGER 

MSG_1NDEX INTEGER 

SEG_DESC_REG RECORD 

L 

RASE ADDRESS 

ATTRIBUTES BYTE 

LIMITS BYTE 

J 



MMU 



ARRAY fNR SDR SSG DESC REGJ 



MSG_TABLE RECORD 
C MSG 
SENDER 
NEXT MSG 
FILLER 



MESSAGE 
VP_INDEX 
MSG_IND£X 
ARRAY [6, 



*(ORrj 
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2! $50 45 



01510 



0000 



0A00 

0A0A 



VP TABLE RECORD 
■ [ Difi ADDRESS 



PR I WORD 
STATE /^ORD 
IDLE_FLAG J^ORD 
PREEMPT WORD 



PHYS_PROCESSOR WORD 
NEXT READY VP VP_INDEX 
MSG_INDEX 
WORD 

ARRAY t?. WORE] 



'^SG_LIST 
SXT_ID 
FILLER 1 



EXTERNAL 

LIST INSERT 



PROCEDURE 



GLOBAL 

bootstrap_entry label 

^SECTION 1TC_DATA 

VPT RECORD 

[ LOCK WORD 

RUNN1NG_LIST ARRAY[NR_CPU WORD] 
ready list array [NR CPU WORDJ 
FREE_IIST MSG_ INDEX 

V1RT_INT_VEC ARRAY[1, ADDRESS] 
FILLER_3 WORD 

VP ARRAY [NR VP, VP_TABLEJ 

MSG_0 ARRAY InR_VP. MSG_TAiISJ 

J 

EXT_VP LIST ARRAY [NR AVAIL VP WORDJ 



SSECTION MMU DATA 



MMU IMAGE RECORD 

■[ 

MMU_STHUCTURE ARRAY [MAX_DBR_NR MMU J 

] 

NEXT_AVAIL_MMU ARRAY rMAX_DBR_NR BYTE] 

PRDS RECORD 

[PHYS_CPU_ID WORD 
LOG_CPU_ID INTEGER 
VP_NR WORD 

IDLE_VP VP_INDEXJ 
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^SECTION ITC_INT_PfiOC 
INTERNAL 

fc)000 GET'rfORS PROCEDURE 

SWAPS VIRTUAL PROCESSORS ’S' 
- ON PHYSICAL PROCESSOR. 

3;c s;c ^ : 19 c ;;c 3^ 3^c 3;c ^ 3^ s;c j;c ^ 3is a^c 3;$ 3;c ^ 3ic 3is V ^ V 



ajc 


PARAMETERS : 




V 


R13: 


LOGICAL CPU # 


a.' 




REGISTER USE: 


a? 


S? 


STATUS REGISTERS 


a? 


V 


R14: 


DER (SIMULATION) 


•»» 




Rib; 


STACK POINTER 


a? 




local 


1 VARIABLES: 


ar 


5? 


Rl: 


READI VP (NEW) 


V 




R2: 


CURRENT VP (OLD) 


a? 




R3; 


FLAG CONTROL WORD 




V 


R4: 


STACK SEG BASE ADDR 


V 


a;* 


Rb: 


STATUS REG BLOCK ADDR 




s;< 


R6: 


NORMAL STACK POINTER 


a? 






ENTRY 







! GET 


STACK BASE ! 


0000 


31E4 


LD 


R4, Rl4(ffSTACK_SEG’-4 ) 


0002 


0004 






0004 


3445 


LDA 


R5, R4(^STATU5_REG_BL0CK ) 


0006 


00F0 


J V V 


SAVE SP ! 


0008 


2F5F 


LD 


0R5, R15 






f aji 3p 


SAVE FCW V V ! 


000A 


7D32 


LDCTL 


R3, FCW 


000C 


3343 


LD 


R4(#F_C_W), R3 


000E 


00F2 








BOOTSTRAP 


ENTRY: ! GLOBAL LABEL ! 






! GET 


ready VP LIST ! 


0010 


61D1 


LD 


Rl, VFT.READY_LIST(R13) 


0012 


0006' 


SELECT 


VP: 






DO ! 


UNTIL EIGIBLE READY VP FOUND ! 


0014 


4D11 


CP VPT.VP.IDLE FLAG(Rl), #ON 


0016 


0016' 






0018 


FFFF 






001A 


5E0E 


IF EC ! VP IS IDLE ! THEN 


001 c 


0030' 






001E 


4D11 


CP 


VPT.VP.PREEMPT(Rl) , »ON 


0020 


0018' 






0022 


FFFF 






0024 


5E0E 


IF 


EQ ! PREEMPT INTERRUPT IS ON ! 



THEN 
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0025 

0028 

002A 

002C 

002E 

0030 

0032 



0034 

0036 

0038 

003A 



003C 

003E 

0040 

0042 

0044 

0046 

0048 



004A 

004C 

004E 

0050 

0052 



0054 

0056 

0058 

005A 

005C 



002C ' 
5E08 


EXIT FROM SSLECT_VP 


003C ' 


FI 


5E08 

0034' 


ELSE ! VP NOT IDLE ! 


5E08 


EXIT FROM SELECT_VP 


003C' 


FI 

! GET NEXT READY VP ! 


6113 
001C ' 


LD R3, VPT. VP.NEXT_READI 


A131 


LD R1 , R3 


E8EC 


OD 



! NOTE: THE READY_LIST WILL NEVER BE EMPTY SINCE 
THE IDLE VP, WHICH IS THE LOWEST PP.I VF, 

WILL NEVER BE REMOVED FROM THE LIST. 

IT WILL RUN ONLY IF ALL OTHER READY VP'S ARE 
IDLING OR IF THERE ARE NO OTHER VP'S ON 
THE READY_LIST. ONCE SCHEDULED, IT 
WILL HUN UNTIL RECEIVING A HDWE INTERRUPT. ! 

! NOTE: R14 IS USED AS DBR HERE. WHEN MMU 

IS AVAILABLE THIS SERIES OF SAVE AND LOAD 
INSTRUCTIONS WILL BE REPLACED BI SPECIAL I/O 
INSTRUCTIONS TO THE MMU. ! 

! PLACE NEW VP IN RUNNING STATE ! 



4D15 

0014' 

0000 


LD 


VPT.VP.STATE(Rl) , #RUNNING 


6FD1 

0002' 


LD 


VPT.RUNNING_LIST(R13) , HI 




f ip 


- SWAP DBR - - ! 


611E 

0010' 


LD 


R14, VPT.VP.DBR(R1 ) 



! LOAD NEW_VP SP ! 

31E4 LD R4, R14 ( #STACK_S EG=^4 ) 

0004 

3445 LDA R5, R4 ( « STATUS_REG_BLOCK ) 

00F0 

215F LD R15, GR5 

! - LOAD NEW FCW - ! 

3143 LD R3, R4(#F_C_V) 

00F2 

7D3A LDCTL FCW, R3 
9E08 RET 

end GETWORK 
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eesc 



61D2 

005E 0002' 



3NTER_MSG_LIST PR0CEEUH3 

»>* INSERTS POINTER TO MESSAGE 

FROM CURRENT_VP TO SIGNALED Vp’!' 
IN FIFO MSG_LIST ~ 

•? 5|% S|* ^|C #i« 3^ 3^ 3|* 5|S 3|* 3^ 3|* 3|« 3yC#|S S|* 3|» 3|« 3|C 3^ 3|« Sfi 3|* ijS *|t 3y« 



3? 


REGISTER USE; 




>:« 


PARAMETERS : 






R8(R9);MSG (INPUT) 




V 


Rl ; SIGNALED VP (INPUT ) 




3? 


R13: LOGICAL~CPU NUMBER 






LOCAL VARIABLES; 






R2; CURRENT VP 






R3; FIRST FREE MSG 




V 


R4; NEXT FREE MSG 


V 


SJC 


R5: NEXT"0 MSG 




sje 


R6; PRESENT 0 MSG 


sjc 



3j|C 3|S 3^ 3|^3^ 3^ 3^e 3^« 3^C 3^ 3;^ 3^ 3^* ^ 3^ 3|^ ^ 3j« 3t«S|C 3|« 3^ 3;|« 7^i J 

ENTRY 

LD R2, VPT.RUNNING_LIST(R13 ) 



! GET FIRST MSG FROM FREE_LIST ! 
0060 6103 LD R3, VPT .FPEE_LIST 
0062 000A' 



0064 0E03 
0066 FFFF 
0068 5E0S 
006A 0073' 
006C 7601 
006E 0060' 
0070 2100 
0072 0004 
0074 5F00 
0076 A900 



I SJC V :jt :(« DJ^JJUG =!« ^ =P S? ! 

CP R3, #NIL 
IF EO THEN 
LDA Rl, S 

LD R0, #M_L_0! MESSAGE LIST OVERFLOW ! 
CALL MONITOR 
FI 

! V V >p 2ND DEBUG '? v v r 



0078 6134 LD R4, VPT.MSG_0.NEXT_MSG(R3^ 

007A 0122' 

007C 6F04 LD VPT.FREE_LIST, R4 

007E 000A' 



0080 763A 
0082 0110' 

0084 2107 
0086 0010 
0088 BA81 
008A 07A0 



! INSERT MESSAGE LIST INFORMATION ! 
LDA R10 ,VPT.MSG_C .MSG(R3) 

LD R7,#SIZS0F MESSAGE 

LDIRB OR10,UR8,R7 
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008C 

008E 



0090 

0092 

0094 

0096 

0098 

009A 

009C 

009E 



00A0 

00A2 



00A4 

00A6 

00A8 

00AA 

00AC 

00AE 



00B0 

00B2 

00B4 

00B6 

00B8 

00SA 

00BC 

00BE 

00C0 

00C2 



6F32^ 


LD 


VPT.MSG_0 .SEND£R{R3 ) , R2 


0120 








1 


INSERT MSG IN MSG LIST ! 


6115 

001E' 


LD 


R5, VPT.7P.MSG_LIST(R1 ) 


0E05 


CP 


R5, #NIL 



FFFF 

5E0S IE EO ! LIST IS EMPTY ! THEN 

00A4' 

! INSERT ^SG AT TOP OF LIST ! 

6E13 ID VPT.7P.MSG_LIST(R1 ) , R3 

001E' 



5E08 ELSE ! INSERT MSG IN LIST ! 
00EC' 

MSG_0_SEARCH: 

DO ! '#HILE NOT END OF LIST ! 
0B05 CP R5, ffNIL 

FFFF 

5E0E IF EO ! END OF LIST ! THEN 

00B0' 

5E08 EXIT FROM MSG_C SEARCH 

00B8' 

FI 



! GET NEXT LINK. ! 



A156 


LD 


R6, R5 


6165 


LD 


R5, VPT.MSG_C.NEXT_MSG(R6) 


0122' 






E8F6 


OD 






! INSERT 


MSG IN list ! 


6F63 


LD 


VPT.MSG_O.NEXT_MSG( h6) , R3 


0122' 








FI 




6F35 


LD 


VPT.MbG_O.NEXT_MSG(R3U R 


0122' 






9E08 


RET 





END ENTER MSG LIST 
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20C2 



0KC2 61D2 
00C4 0002' 



GST_FIRST_MSG PROCEDURE 

- REMOVES MSG FROM MSG_IIST 

’i' AND PLACES ON FREE LIST. ^ 

RETURNS SENDER'S MSG AND 

- VP_ID 

-REGISTER USE: ’i' 

PARAMETERS t 

R8(R9): MSG POINTER (INPUT'I 
R13: LOGICAL CPU NUMBER (INPUT)- 





Rl : 


SENDER VP (RETURNED) 


3!C 


3? 


LOCAL 


, VARIABLES 


3«5 




R2: 


CURRENT VP 


V 


3;« 


R3 : 


FIRST MSG 




3je 


R4: 


NEXT MSG 


3JC 




R5: 


NEXT_FREE_MSG 






R6: 


PRESENT FREE MSG 


3? 



ENTR'^ 

LD R2, VPT.RUNMNG_LIST(R13^ 



! REMOVE FIRST MSG FROM MSG_LIST ! 
00C6 6123 LD E3, VPT.VP.MSG IIST(R2) 

00C8 001E' 



e-^CA 


0B03 


00CC 


FFFF 


00CE 


5E0E 


00D0 


00DE' 


00D2 


2100 


00D4 


0001 


00D6 


7601 


00D8 


00D6 ' 


00DA 


5F00 


00DC 


A900 



00DE 

00E0 


6134 

0122' 


LD 


00E2 

00E4 


6F24 

001S' 


LD 


00E6 

00E8 


6105 

000A' 


LD 


00EA 

00EC 


0B05 

FFFF 


CP 


00EE 

00F0 


5E0E 

0100' 


IF EO 



j V V V V debug 

CP R3, #NIL 
IF EO then 
LD R0, #M_L_EM 
LDA Rl, $ 

CALL MONITOR 



ifi Sfi 5,5 f 



! MSG LIST EMPTY 



FI 

I 5^ V 5 ? i^jyjD DEBUG '7 ^ ! 

R4, VPT.MSG_C .NSXT_MSG(R3) 

VPT.VP.MSG_LIST(R2) , ?.4 

! INSERT MESSAGE IN FREE LIST ! 
R5, VPT.FREE_LIST 

R5, #NIL 

! FREE LIST IS EMPTY ! TEEN 
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! INSJ!.iiT AT TOP OF LIST ! 

00F2 6F03 LD VPT . FR53_L IS T , R3 

00F4 000A' 

00F6 4E35 LD VPT.f^SG Q . NLXT_!^SG (R3 ) 

00F8 0122' 

00FA FFFF 

00FC 5E08 ELSE ! INSERT IN LIST ! 

00FE 0110' 

FREE C SEARCH: 

DO 



0100 

0102 


0E05 

FFFF 


CP 


R5, )?NIL 


0104 

0106 


5E0E 

0100' 


IF EO 


! END OF LIST ! THEN 


0108 

010A 


5E08 

0114' 


EXIT 

FI 

! GET 


FROM FREE_g_SEARCH 
NEXT MSG ! 


0100 


A156 


LD 


R6, R5 


010E 

0110 


6165 

0122' 


LD 


R5, VPT.MSG C.NEXT MSG 


0112 


E8F6 


OD 





, f*N 



(Re) 



! INSERT IN LIST ! 



0114 

0116 


6F63 

0122' 


LD 


VPT.MSG_0.NEXT_MSG(R6) , R3 


0118 

011A 


6F35 

0122' 


LD 


VPT.MSG_0.NEXT_MSG(R3) , R5 



FI 

! GET MESSAGE INFORMATION: 
(RETURNS Rl: SENDING 7P ) ! 



0110 


6131 


LD 


Rl, VPT.MSG_0.SENDER(R3) 


011E 


0120' 






0120 

0122 


763A 

0110' 


LDA 


R10 ,VPT.MSG_0.MSG(R3) 


0124 

0126 


2107 

0010 


LD 


R7,^^S1ZE0F MESSAGE 


0128 

012A 


BAAl 

0780 


LDIRB 


OR8,(.'JR10,R7 


0120 


9E08 


RET 




012E 




END GET 


FIRST MSG 



! ^ INNER TRAFFIC CONTROL ENTRY POINTS - - 



I 



! NOTE: AIL INTERRUPTS MUST BE MASKEE WHENEVER 
THE VPT IS LOCKED. THIS IS TO PREVENT AN 
EMBRACE FROM OCCURRING SHOULD AN INTERRUPT 
OCCUR WHILE THE VPT IS LOCKED. ! 

GLOBAL 

SSECTION ITC_GLB_PROC 

PP.ESMPT_RET LABEL 
KERNEL EXIT LABEL 

0000 CREATE_INT_VEC PROCEDURE 

creates entry in virtual int-** 

ERRUPT VECTOR WITH ADDRESS - 
’i' OF THE VIRTUAL INTERRUPT HAN-^- 
“S' DLER. 

2f« «y( 3|C 3y% 3|« «g* 2|£ 4 ^ ^|« «|C ifi Sfi 3 ^ 3^ «i* 

^ PARAMETERS: 

R1 : virtual INTERRUPT # 

R2: interrupt HANDLER ADDR - 



ENTRY 

! COMPUTE OFFSET IN VIRTUAL 

interrupt vector ! 

0000 1900 MULT RR0, »SIZE0F ADDRESS 

0002 0002 

! SAVE ADDRESS OF VIRTUAL INTERRUPT 
HANDLER IN INTERRUPT VECTOR ! 

0004 6F12 LD VPT.VIRT_INT_VSC(R1 ) , P.2 

0006 000 c' 

0008 9E0B RET 

000A END create I NT VEC 
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eeeA 



00i)A 

000C 



000E 

0010 

0012 



GET DBH ADER PROCECHRE 

CALCULATES DEH ADDRESS FROM - 
DBR NUMBER 

^ 9^ 3ie :gc :(c:iic sp 9^ 3ie 3^ 3^ :;; sp 3^ V >r ^ 9 



5(5 


REGISTER USE: 






PARAMETERS : 






P.0: DBR 






RETURNS : 






Rl; DBR ADDRESS 





:s{3it3p3ie3ie3!c3iS3it3p3^3p:5e3!e3?Jp3je3?3is3?3!e3^SiS3iS3iS3ie3it3?3^3;{3js3;s:;t J 

ENTR^ 

! GET BASE ADDRESS OF MMU IMAGE ? 

7601 LDA Rl, MMU_IMAGE 

0000 ' 

! ADD DBR HANDLE (OFFSET) TO MMU EASE 
ADDRESS TO OBTAIN DBR ADDRESS ! 

8101 ADD Rl, R0 

9E08 RET 

END GET DBR ADDR 



0feJl2 



0012 

0014 



0016 

0018 

001A 

001C 

001E 

0020 

0022 

0024 

0026 

0028 

002A 

002C 

002E 

0030 

0032 

0034 

0036 

0038 

003A 

003C 

003E 

0040 

0042 

0044 

0046 



ALLOCATE_MMU PROCEDURE 

ALLOCATES NEXT AVAILABLE MMU ^ 
IMAGE AND CREATES PRDS ENTRY 



5? 


REGISTER USE; 






RETURNS ; 






R0; DBR # 






LOCAL VARIABLES; 


S|C 




Rl ; SEGMENT a 


ajc 




R2; PRDS ADDRESS 


ajs 


a? 


R3; PRDS ATTRIBUTES 


V 




R4; PRDS LIMITS 





ENTRY 

! GET NEXT AVAILABLE DBR # ! 

SD08 CLR R0 

SD18 CLR R1 

1 NOTE; THE FOLLOWING IS A SAFE SECUENCE 
AS NJ!iXT_AVAlL_'^MU AND MMU ARE CPU LOCAL! 
GET_DER; 

DO 

4C11 CPE next_avail_mmu(ri) , ^^AVAILABLE 

0A00' 

0000 

IF EO !MMU ENTRY IS AVAILABLE! 

5E0E THEN 

002E' 

4C15 LDB NEXT_AVAIL_MMU(R1) , #ALLOCATED 

0A00' 

FFFF 

5E08 EXIT PROM GET_DER 

004A' 

5E08 ELSE !CURRENT ENTRY IS ALLOCATED! 

0048' 

A910 INC Rl, #1 

0100 ADD R0, #SIZEOF YMU 

0100 

j ss V V V DEBUG V V V I 
0E01 CP Rl, #MAX_DBR_NR 

000A 

5E0E IF EO THEN 

0048' 

2100 LD R0, #M_U !MMU UNAVAILABLE 

0007 

7601 LDa Rl, $ 

0040 ' 

5F00 CALL MONITOR 

A900 

FI 

J 5): V 



END DEBUG ^ v \ 



0048 


E8E6 


1 

o 


004A 


2101 


LD 


004C 

004E 


0000 

7602 


LDA 


0050 

0052 


0A0A' 

2103 


LD 


0054 

0056 


0001 

2104 


LD 


0058 


0000 


! PRDS 



P.1, #PRDS_SE(} 
R2, PHDS 
R3, ! read 

R4, #{(SIZSOF 
LIMITS ! 



! SEGMENT NO. ! 
! PRDS ACDH ! 
ATTR ! 

PRDS )-l)/2£e 



0{^5A 

00bC 



5F00 

0060' 



! CREATE PRDS ENTRY IN MMU IMAGE ! 

CALL UPDATE MMU IMAGE !(R1: SEGMENT ^ 



RET 

END allocate MMU 



R2: SEG ADDRE 
RS: ATTRIBUTE 
R4: SEG LIMITS) 



005E 9E08 
0060 



C/» ry3 



0064J UPrATfi_MMU_lMAGE PROCEEURE 







CREATES SEGMENT DESCRIPTOR 
ENTRY IN MMU IMAGE 


3? 

3*5 






•r* ^ ^ ^ •r* 'll* ^ *1* *1* 


r,S 






REGISTER USE: 
PARAMETERS: 








- R0: DBR # 








=" R1 : SEGMENT 


3? 






R2: segment ADDRESS 


3? 






- R3: SEGMENT ATTRIBUTES 








R4: SEGMENT LIMITS 








’i' LOCAL VARIABLES: 


3? 






^ R10: MMU EASE ADDRESS 


3i* 






R13: OFFSET VARIABLE 


3(4 






ap3jc3?3;«a^sjs3ss>j:3jcjjc3?3;c::p3p;:p:p^a;c;;:jjcs;c3;c3jc3jsais3;cy,c^3}:;;«3is^« f 






ENTPT 




0060 


210A 


LD R10, #MMU IMAGE ! MMU BASE ADDRESS ! 


0062 


0000' 






0064 


S10A 


ADD Rie, R0 




0066 


210D 


LD R13, #SIZEOF SEG_DESC_HEG 




006B 


0004 






006A 


991C 


MULT RR12, R1 ! COMPUTE SEG 


DESC OFFSET 


006C 


eiDA 


ADD E10, R13 !ADD OFFSET TO 
! INSERT DESCRIPTOR DATA ! 


BASF ADDRESS 


006E 


2FA2 


LD OR10, R2 




0070 


A9A1 


INC R10, #2 




0072 


0DA8 


CLR GR10 




0074 


2EAC 


LDB GR10, RL4 




0076 


A9A0 


INC R10, #1 




0078 


20AC 


LDB RL4, GR10 




007A 


0A0E 


CP3 RL3, #i;(2)00001000 ! EXECUTE ! 


007C 


0808 






007E 


5E0S 


IF EO TEEN 




0080 


008A' 






0082 


060C 


ANDB RL4, #%( 2 ) 11110111 


! EXECUTE ^ 


0084 


F7F7 






0086 


5E08 


ELSE 




0088 


008E' 






008A 


060C 


ANDB RL4, #%(2)11111110 


! READ MASK 


008 C 


FEFE 


FI 




008E 


84BC 


ORB RL4, RL3 




0090 


2SAC 


LDB GR10, RL4 




0092 


9E08 


RET 




0094 




END nPDATE_MMD_lMAGE 





^^^b 



0094 



0094 7C01 

0096 7604 
0098 0000' 
009A 5F00 
009C 0’^82' 



00AE 001E' 
00S0 FFFF 
00B2 5E0S 
00B4 00EA' 



00E6 0B03 
00B8 FFFF 
00BA 5E0E 
00EC 00CA' 
00BE 2100 
00C0 0003 
00C2 7601 



WAIT PROCEDURE 

- INT^A_KERNEL STNC/COf^ PRIMATIVS v 
INVOKED EY KERNEL PROCESSES 

;(C 9ic ^ ;ip ^ ;:c qc V V ^ ^ >r 3r V ’It ^ ^ ^ ^ 

'•* PARAMETERS 

’i' R8(R9): MSG POINTER (INPUTS 

’i' R1 : S£NDING_VP (RETURN) 

- GLOBAL VARIABLES 

R14: DER (PARAM TO GETWORK ^ 

’i' LOCAL VARIABLES 

- R2: CURRENT_VP (RUNNING) 

R3: NEXT_READY_VP 

^ R4: LOCK ADDRESS 

^ R13: LOGICAL CPU NUMBER - 

ENTRY 

! MASK INTERRUPTS ! 

DI VI 
! LOCK VPT ! 

LDA R4, VPT. LOCK 









SP 



CALL 



SPIN LOCK ! (R4:''VPT.L0CK) ! 



! NOTE: RETURNS WHEN VPT IS LOCKED Elf THIS VP ’ 
! GST CPU NUMBER ! 



HI :CPU ff 
R2:# VP'S! 



009E 

00A0 


5F00 

02C8' 


CALL 


GET 


00A2 


AllD 


LD 


R13 


00A4 

00A6 


61D2 

0002' 


LD 


R2, 


00A8 

00AA 


6123 
001C ' 


LD 


R3, 


00AC 


4D21 


CP 


VPT 



VPT.VP.MSG_LIST(R2) , #NIL 

I? EC ! CURRENT VP'S ^-SG LIST IS EMPT^ ! THEN 

! REMOVE CURRENT_VP FROM READY_LIST ! 
f D ^ 2 U G *•' '** ! 

CP R3, #NIL 

IF EC THEN 

LD R0, #R_L_E ! READY LIST EMPTY ! 
LDA ai, $ 
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00C4 


00C2' 






00C6 


5F00 




CALL MONITOR 


00C8 


A900 




FI 

! ^ END DEBUG v i 


00CA 


6FD3 


LD 


VPT.R£ADT_LIST(R13) , R3 


00CC 


0006' 






00CE 


4D25 


LD 


VPT. VP .NEXT_READY_VP (R2'i , <^NIL 


00D0 


001C' 






00D2 


FFFF 


! PUT 


IT IN WAITING STATE ! 


00D4 


4D25 


LD VPT 


.VP.STATS(R2) , ^^WAITING 


eeD6 


0014' 






00D8 


0002 


! SET 


DPR ! 


00DA 


612E 


LD 


R14, VPT.VP.DfR(R2) 


00DC 


0010' 










! SCHEDULE FIRST ELGIBLi READY VP ! 


00DE 


93F8 


PUSH 


GRlb.RB 






! SAVE 


LOGICAL CPU tt ! 


00E0 


93FD 


PUSH 


ORlb, R13 


00E2 


5F00 




CALL GET WORK !R13:C?U a 


00E4 


0000' 




R14 :DER ! 






! RESTORE CPU ft ! 


00E6 


97FD 


POP 


R13, 0R15 


00E8 


97F8 


POP 


R8,0R15 



FI 

! GET FIRST !^SG ON CURRENT VP'S ^'SG LIST ! 



00EA 5F00 CALL GET FIRST_.'^SG ! COPIES MSG IN MSG AREA 
00EC 00C2' 

! R13: LOGICAL CPU 
! RETURNS RlrSENLER 

! UNLOCK VPT ! 

00EE 4D08 CLR VPT. LOCK 
00F0 0000' 

! UNMASK VECTORED INTERRUPTS ! 

00F2 7C05 SI VI 

! RETURN: Rl:SENDER VP ! 

00F4 9E08 RET 

00F6 END WAIT 






00F6 



00F6 

00F8 



00FA 

00FC 

00FE 

0100 



0102 

0104 



0106 

0108 



010A 

010C 



010S 

0110 

0112 

0114 

0116 



0118 

011A 



SIGNAL PROCEDUEE 

INTRA KERNEL SYNC /COM PRIMATIVE - 
^ INVOKED PY KERNEL PROCESSES - 

3;c 3^ ^ ^ »;c 3^c ^ ^ ^ ^ 2;; ^ >,c 

- REGISTER USE; 

PARAMETERS : 

R8(R9); MSG POINTER (INPUT) 

- R1 : SIGNALED VP_ID (INPUT) - 

^ GLOBAL VARIABLES 

- R13: CPU # (PARAM TO GETWORK ) 

- R14: DER (PARAM TO GETWORK) 

LOCAL VARIABLES: 

’i* Rl; signaled VP - 

R2: CURRENT_VP - 

’i' R4; VPT.LOCK ADDRESS 

ENTR^ 

! SAVE VP ID ! 

93F1 PUSH PR15, Rl 

! mask INTERRUPTS ! 

7C01 DI VI 

! LOCK VPT ! 

7604 LDA R4, VPT.LOCK 

0000 ' 

5F00 CALL SPIN_LOCK ! (R4 VPT . DO CK ) ! 

0282' 

!NOTE: RETURNS WHEN VPT IS LOCKED BY THIS VP. 
! GET LOGICAL CPU n ! 

5F00 CALL GET_CPU_NO ! RETURNS: 

02C8' 

RlrCPU 
H2:tt VP'S! 

AllD LD R13, Rl 

! RESTORE VP ID ! 

97F1 POP Rl, (3R15 

! PLACE MSG IN S IGN ALED_VP 'S MSG_LIST ! 

5F00 CALL ENTEP_MSG_LIST !(R8;MSG POINTER 
005C' Rl :SIGNAL£D_VP 

R13: LOGICAL CPU ??) ! 

4D11 CP VPT.VP.STATE(R1 ) , ^rWAlTlNG 

0014 ' 

0002 

5E0E IF SO ! SIGNALED_VP IS WAITING ! THEN 
0148' 

! WAKE IT UP AND MAKE IT READY ! 

A112 LD R2, Rl 

76D3 LDA R3, VPT. READY LiST(Rl3) 
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011C 


0006 ' 








011B 


7604 


LDA 


R4, 


VPT.VF.NEXT_R£ADY 


0120 


001C' 








0122 


7605 


LDA 


R5. 


VPT.VP. PRI 


0124 


0012' 








0126 


7606 


LDA 


R6 , 


VPT. VP. STATE 


0128 


0014' 








012A 


2107 


LD 


R7, 


#RSADT 


012C 


0001 


! SAVE 


LOGI 


CAL CPU ff ! 


012E 


93FD 


PUSH 


0R15, R13 


0130 


5F00 


CALL 


LIST INSERT !R2: ORJ 


0132 


0000=«' 









H3: 


LIST PTR 


ADD?, 


R4 : 


NEXT OEJ 


PTR 


R5 : 


priority! 


PTR 


R6: 


STATE_?TR 




R7: 


STATE ! 





! RESTORE LOGICAL CPU n ! 



0134 


97FD 


POP 


R13, GR15 






! PUT 


CURRENT VP IN READT STATE ! 


0136 


61D2 


LD 


R2, 7PT.RUNNING_IIST(R13^ 


0133 


0002' 






013A 


4D25 


LD 


VPT. VP. STATE ( R2 ) , <?READY 


013C 


0014' 






013E 


0001 


» PT 

• *j j. 


D3R ! 


0140 


612E 


LD 


R14, VPT.VP.DPR(R2 ^ 


0142 


0010' 










! SCHEDULE FIRST ELGIELE READY vp ! 


0144 


5F00 


CALL 


GETWORK !R13;I0GICAL CPU 


0146 


0000' 


FI 


?14:DBR ! 






! UNLOCK VPT ! 


0143 


4D08 


CLR VPT. LOCK 


014A 


0000' 










! UNMASK VECTORED INTERRUPTS ! 


014C 


7C05 


El 


VI 



014E 9E08 RET 
0150 END signal 
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fe;i50 



SET preempt procedure 

SETS preempt interrupt ON- 

- TARGET_?P. CAlIED BT TC_ 

ADVANCE. 

s.-; j;; jp JS sp V V V V sp >? 5? 5? 5? sp ap ir V »? >;« JP =P s? 

- REGISTER USE: 

PARAMETERS : - 

PI :TARGET_VP_ID (INPUT) - 

- LOCAL VARIABLES - 

^ Rl: VP_ INDEX =5* 

vapp<apapp:>p:p I 

ENTPT 

!*NOTE: DESIGNED AS SAEE SEC'JENCE SC 
NOT BE LOCKED. ! 



jp 

sp 



VFT NEED 



0150 

0152 



6112 

0210 ' 



! CONVERT 
ID 



V?_ID TO VP INDEX ! 
R2. EXT VP LIST(R1^ 



0154 4D25 
0156 0018' 
0158 FEFF 



! TURN ON TGT_VP PREEMPT FLAG ! 

ID VPT.VP.PREEMPT(R2) . #0N 



! IF TARGET VP NOT LOCAL 

( NOT BOUND TO THIS CPU ) 

(IE, IF <<cpu_seg»cpu_id<>vpt.vp.fkys_cpu(ri) 

TEEN SEND HARDWARE PREEMPT INTERRUPT TO 
VPT.VP.CPU(Rl) . ! 



01 5A 9E08 
015C 



RET 

END SE' 



PREEMPT 
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015C 



IDLE PROCEDURE 

f 'I* «y« ifi 2|« j|« «|« •!* »|* *1% «|» »|C 

LOADS IDLE DBR ON 
^ CURRENT VP. CALLED B'i - 
'•* TC_GETWO^fC. 

3^ 3jc ^ 3^ 3^ :;c ^ :;c 

- REGISTER USE - 





GLOBAL variable 


3|« 


3? 


R13: LCG CPU # 


V 


V 


PI 4: DBR 


V 




LOCAL VARIABLES: 


3.5 




R2: CURRENT VP 




3«C 


R3; TEMP VAR 


3? 




R4: 7PT.L0CK ADDR 


3.5 


J?e 


R5: TEMP 


nS 



015C 5F045 



^>iS5i£S?J!S!?S?>i«5i«»itn:’?5PS!C>?S?S?SiSS?SiCJ;!S?V5r5;e J 

ENTRY 

! GET LOGICAL CPU # ! 

CALL GET CPU NO ! RETURNS 



! LOAD IDLE DBR ON CURRENT VP ! 



0174 


6103 


LD 


R3, PRDS.IDLE_VP 


0176 


0A10' 






017S 


6135 


LD 


R5, VPT.VP.DBR(R3) 


017A 


0010' 






017C 


6F25 


LD 


VPT. VP. DBR (R2), R5 


017E 


0010' 










! TURN ON CURRENT VP'S IDLE FLAG ! 


0180 


4D25 


ID 


VPT .VP. IDLS_FLAG(R2) , ^^ON 


0182 


0016' 






0184 


FFFF 










! SET 


VP TO READY STATE ! 


0186 


4D25 


LD 


VPT.VP.STATE(R2), #RSAEY 


0188 


0014' 






016A 


0001 










! SCHEDULE FIRST ELIGIBLE READY VP 


018C 


5F00 


CALL 


GETWORK !R13:L0GICAL CPU « 


018E 


0000' 












R14:DRR ! 






! UNLOCK VPT ! 


0190 


4D08 


CLR 


VPT. LOCK 


0192 


0000' 










! UNMASK VECTORED INTERRUPTS ! 


0194 


7C05 


SI 


VI 


0196 


9E08 


RET 




0198 




END IDLE 



214 



^198 



0198 93F1 

019A 7C01 

019C 7804 
019E 0000' 
01A0 5F00 
01A2 0282' 



01A4 5F00 
01A6 02C8' 



01A8 AllD 

01AA 61D2 
01AC 0002' 

01AE 4D21 
01JJ0 001E' 
01B2 FFFF 
01B4 5S08 
01B6 01C4' 
0138 2100 
01BA 0005 
01BC 7601 
01BE 01EC ' 
01C0 5F00 
01C2 A900 



SWAP 7BER PROCEDURE 

v; rz 2^ vr.rr n ' r rt xr rt xs xsrsi-S rr xi x: 



LOADS NEW DBR ON 
CURRENT VP. CALLED 3 - 

- TC_GETWORK. 

’i' REGISTER USE 

- PARAf^ETERS - 

^ Rl: NEW_DBR (INPUTS 

- GLOBAL variables 

- R13: LOGICAL CPU # - 

R14: DBR - 

^ LOCAL VARIABLES - 

- R2: CURRENT VP - 

R4: VPT.LOCK ADDR ^ 

ENTRY 

! SAVE NEW DBR ! 

PUSH PR15, Rl 

! MASK INTERRUPTS ! 

DI VI 
! LOCK VPT ! 

LDA R4, VPT.LOCK 



CALL SPIN lock ! (R4 :''VPT .LOCK ) ! 



! NOTE: RETURNS WHEN VPT IS LOCKED BY THIS VP. 
! GET CPU # ! 

CALL GET_CPU_NO. ’RETURNS: 

Rl: CPU ^ 

R2:f^ VP'S! 

L r R 1 3 R 1 

! GET current’ VP ! 

LD R2, VPT.RUNNING_LIST(R13) 

I >? :? V debug V s;! v I 

CP VPT. VP. MSG LIST(R2), ^^NIL 



IF NE ! MSG WAITING ! THEN 
LE R0, #S_N_A ! SWAP NOT ALLOWED 
LDA Rl , $ !PC ’ 

CALL MONITOR 
FI 

! - END DEBUG ! 

! SET DBR ! 
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eiC4 


612E 


LD 


?.14, VPT.VP .DEH(R2) 


H1C6 


0010 ' 










! REST 


ORE NEW DBR ! 


eiC8 


97?0 


POP 


R0, (?R15 


;?iCA 


5200 


CALI 


OET_DBR_ADDR ! fR0; I3R ff) 


e!icc 


000A' 












RETURNS 








(Rl: EBR AEIR) 






! LOAL 


NEW DBR ON CURRENT V? ! 


01C2 


5221 


LD 


VPT.VP.DER(R2) . Rl 


diDfd 


0010 ' 










! TURN 


OFF IDLE FLAG ! 


eiD2 


4D25 


IE 


VPT.VP.IDIS_FIAG(R2) , ?^CFF 


01M 


0016 ' 






01D6 


0000 










! SET 


VP TO READY STATE ! 


011)6 


4E25 


LD 


VPT.VP.STATE(R2 ) , «REAEI 


eiDA 


0014 ' 






01DC 


0001 










! SCHEDULE FIRST ELGIELE READK VP ! 


eiDE 


5F00 


CALL 


GETWORK !R13:I0GICAL CPU » 


01E0 


0000 ' 












R14:DER ! 






! UNLOCK VPT ’ 


01E2 


4D08 


CLR VPT. LOCK 


01E4 


0000' 










! UNMASK VECTORED INTERRUPTS ! 


0126 


7C05 


£I 


VI 


01£8 


9E08 


PET 




01SA 




END S'iAP 


_VDBR 



Z16 



eiEA 



PEYS_PRi^i:r"PT_HANI}LER PROCEIURE 

- hardware PRSEr^PT INTERRUPT - 
HANDLER. ALSO TESTS PGR 

V VIRTUAL PREEMPT INTERRUPT ^ 

- FLAG AND INVOKES INTERRUPT 

- HANDLER IF FLAG IS SET. 

- INVOKED UPON EVERY EXIT FROi^ ^ 

- KERNEL. KERNEL FC'W i^.ASKS - 

NVI INTERRUPTS TO PREVENT 
SIMULTANEOUS PREEMPT INTERR. 
HANDLING. 

3|s;(S)^3icsiC ;^>;£3;c:;c 3^ 3yC3iC3)C3;c3;s3(cv^^^^^ 



REGISTER USE - 

- LOCAL VARIAPLES 

Rl: PREEMPT_INT_FLAG 

- R2: CURRENT VP 



- GLOBAL VARIABLES 
^ R13:L0GICAL CPU ^ 
^ P14:DBR 






#1% #1% •!% #1% I 



ENTRY 



1 :;t =;< preempt HANDLER ^ ^ ! 







! SAVE 


ALL REGISTERS ! 


01EA 


030F 


SUB 


R15, #32 


01EC 


0020 






01EE 


1CF9 


LDM 


0R16, Rl. #16 



fe'lFO aiHF 



2U2 7D67 
fe?lF4 93F6 

01F6 5Fe0 
01FB (d2C8' 



01EA AllD 

01FC 7C01 

01FE 7604 
0200 0000 ' 
0202 5F00 
0204 0282' 



0206 61D2 



! SAVE NORMAL STACK POINTER (NS?) 
LDCTL R6, NSP 

PUSH OR15, R6 

! GET CPU f* ! 

CALL C-ET_CPU_NO 'RETURNS: 

Hi: CPU ^ 

R2:ti VP 'S ! 

LD P.13, Rl 

MASK INTERRUPTS ! 

DI VI 
! LOCK VPT ! 

LDA R4, VPT. lock 

CALL SPIN_LOCK 

! RETURNS WHEN VPT IS LOCKED! 

! SET DBR ! 

LD R2, VPT. RUNNING LIST(R13) 
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0208 0002 
020 A 612S 
020C 0010 



LD ' 



R14, VPT.VP.DER(R2) 







! PUT 


CURRENT PROCESS IN R 


EADY 


ST! TE 


020E 


4D25 


LD 


VPT. VP.STATE(R2) , 


#HE 


ACY 


0210 


0014' 










0212 


0001 










0214 


5F00 


CALL 


GSTiCRK !Ri;3:LOG 


CPU 


tt 


0216 


0000' 




R14:DER 


j 








PREEMPT 


RET • 











! UNLOCK VPT ! 


0218 


4D08 


CLP VP'^.LOCK 


021A 


0000' 


! UNMASK VECTORED INTERRUPTS ! 


021 C 


7C05 


El VI 



KERNEL EXIT: 

I UNMASK VIRTUAL PREEMPTS ! 

! NOTE: SAFE SEQUENCE AND EOES NOT REQUIRE 
7PT TO BE LOCKED. ! 







! GET 


CURRENT VP ! 


021E 


610D 


LD 


R13, PRDS.IOG_CPU_ID 


0220 


0A0C ' 






0222 


61D2 


LD ?.2 


, 7PT.RUNNING_LISTfRl3) 


0224 


0002' 










j PPE2MPT INTERRUPT FLAG •' 


0226 


4D21 


CP 


VPT.VP.PHEEMPT(R2 1 . ^^ON 


0228 


0018 ' 






022 A 


FPEp 






022C 


5E0E 


IF SO 


! PREEMPT FLAG IS CN ! THEN 


022E 


0240' 


; 


RESET PREEMPT FLAG ! 


0230 


4D25 


LD 


VPT.VP.PREEMPT(R2^ , »OFF 


0232 


0018 ' 






0234 


0000 


! 


SIMULATE VIRTUAL PREEMPT INTERRUPT 


0236 


2101 


LD 


Rl, 


0238 


0000 






023A 


6112 


LD 


R2, VPT.VIRT_INT_VEC (Rl ) 


023C 


000C ' 






023E 


1S28 


JP 


0^2 



!NOTE: THIS JUMP TO TRA?FIC_CONTROi 
IS USED ONLY IN THE CASE UP A PREEMPT INTERRUPT, 
AND SIMULATES A HARDWARE INTERRUPT. -- ! 

! END VIRTUAL PREEMPT HANDLER ! 

FI 
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! NOTE: SINCE A HDWE INTERRUPT DOSS NOT EXIT 
THP.UUUF THE OATS, THOSE EUNCTIONS PROVIDED 
31 A GATE EXIT TO HANDLE PREEMPTS MUST EE 
PROVIDED HERE ALSO. ! 

! RESTORE NSP ! 



0240 


9'7Fb 


POP R6, 


0R15 


0242 


7D6F 


LDCTL 


NSP, R6 






! RESTORE ALL REGSTER 


0244 


ICFl 


LDM 


Rl, 0R16, 


0246 


010F 






0248 


010F 


ADD 


R15, #*22 



(/24:A eeno 

! EXECUTE HARDWARE INTERRUPT RETURN ! 
024C 7E00 IRET 

024E END PHYS PREEMPT HANDLER 
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p_NN_lNG_yP PHOCijlJ'JRE 

f «|* ^1* Sfi Sfi 2^ 2)% «i« 2|« 3i|« 3^« 2|* #,C 2|« ifi ifi 2|C 2|« 2|« 2^S S|* 2|« *,« ifi 3^C 2|C 3fi 2|C 2^« 

CALLED £Y TRAFFIC CONTROL. =" 
==» RETURNS VP ID. RESULT IS VALID’'-' 

- ONLY WrilLE'APT IS LOCKED. 

3^ 3ic V ^ ^ 7 ^ ^ V ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 

’i' REGISTER USE 

’•' PARAMETERS ’■' 

Rl: EXT_VP_ID (RETURNED) - 
’!' R3: LOG CPU > (RETURNED) ’'■' 

- LOCAL VARIABLES 

’i' R2: VP INDEX 

ENTRY 

I MASK INTERRUPTS ! 



024E 


7C01 


DI VI 








! LOCK VPT ! 


C25e 


7604 


LDA 


R4, VPT. LOCK 


0252 


0000' 






0254 


5F00 


CALL 


SPIN_LOCK ! (R4;''VPT.L0CK ) ! 


0256 


0282' 










! NOTE; RETURNS 'J/HEN VPT IS LOCKED RY THIS 
! GET LOGICAL CPU ! 


0258 


5F00 


CALL 


GET_CPU_NO IHETURNS; 


025 A 


02CB ' 




Rl; CPU # 
R2:# VP'S! 


025C 


A113 


LD 


R3, Rl 


025E 


6132 


LD 


R2, VPT.RUNNING_LIST(R3) 


0260 


0002' 










! CONVERT 


V? INDEX TO VP ID ! 


0262 


6121 


LD 


Rl, VPT.VP.EXT_ID(R2) 


0264 


0020' 




DERUG 5? »:« >? ! 


0266 


0E01 




CP Rl, */NIL 


0268 


FFFF 






026A 


5E0E 




IF EQ ! KERNEL PROC ! THEN 


026C 


027A ' 






026E 


2100 




LD R0, ^#V_I_E ! VP INDEX ERROR 


0270 


0006 






0272 


7601 




LDA Rl, S 


0274 


0272 ' 






0276 


5F00 




CALL MONITOR 


0278 


A900 




FI 

! ^ END DEBUG ^ ! 






! UNLOCK 


VPT ! 


027A 


4D08 


CLR 


VPT. LOCK 


027C 


00 00 ' 


! UNMASK 


VECTORED INTERRUPTS ! 


027E 


7C05 


El VI 




0280 


9E08 


RET 




0282 




END RUNNING 


V? 
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0882 0D41 
0284 0000 
0286 5E06 
0288 0296' 
028A 2100 
028C 0000 
026S 7601 
0290 026E' 
0292 5F00 
0294 A900 



0296 0D46 
0298 E5FE 



029A 9E06 
029C 



SPIN LOCK FP.OCSDTJRE 

USES SPIN_LCCK MECh. 

- LOCKS UNLOCKED DATA 
*:' STHUCTUHE (POINTED TO ’i' 
BY INPUT PARAMETER). - 



’^‘REGISTER USE 
^ PARAMETERS - 

- P4: LOCK ADDR (INPUT)- 

s;t3sc:^^3ic)ic3ic:^3ic3^3ic:^:^3e(^3ic:;e3ic9ic^3;ssicj^^:;: J 

ENTRY 

t NOTE: SINCE ON L"^ ONE PROCESSOR CURRENTLY 
IN SYSTEM, LOCK NOT NECESSARY. ! 
j debug ^ I 

CP GR4, itOFF 

IF NE ! NOT UNLOCKED ! THEN 
LD R0, PU_L ! UNAUTHORIZED LOCK ! 

LDA R1 , S 
CALL MONITOR 
FI 

! END DEBUG ! 

TEST_LOCK: 

! DO WHILE STRUCTURE LOCKED ! 

TSET GR4 

JP TEST_LOCK 

! -- NOTE SEE PLZ/ASM MANUAL 
FOR RESTRICTIONS ON 
USE OF TSET. -- ! 

RET 

END SPIN LOCK 
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ITC_GST_SEG_PTR PROCEDURE 

GETS BASE ADDRESS OF SEGr^ENT - 
’*' INDICATED. - 

5 j% 5 |t a,» a|« 3 |c ajc 5 |% ajc 35c 3 |« ap #^s ^ aj% #|S 35€ ajc ajc ajs ?j% 35s Ji* #(C aj% ajc ajs 55s a^c 



REGISTER USE: - 

R0;SEG BASE ADDRESS (RET ^ 

RltSEG N^ (INPUT) 

- R2 :RUNNING_VP (LOCAi) - 

R3:D£R_VALUS (LOCAL) 

^ R4:7PT.LOCK - 

- Rl 3: LOG I CAL CPU tt 



e29C 93F1 

029E 7C01 

02A0 7604 
02A2 0000' 
02A4 5F00 
02A6 0282' 

02AB 5F00 
02AA 02C8' 



02AC AllD 

02AE 97P1 
02B0 61D2 
02B2 0002' 
02B4 6123 
02B6 0010' 

02B8 4D08 
02BA 0000' 

02BC 7C0b 
02BE 1900 
02C0 0004 
02C2 7130 
02C4 0100 



ENTRY 
! SAVE 


SEGMENT n ! 


PUSH 


0R15, R1 


! MASK 


INTERRUPTS ! 


DI 


VI 


! LOCK 


VPT ! 


LDA 


R4, VPT. LOCK 


CALL 


SPIN_LOCK !R4: ''VPT. LOCK! 


! GET 


CPU # ! 


CALL 


GFT_CPU_NO !RETURNS: 


LD 


R1 : CPU n 
R2:# VP 'S ! 

R13, R1 


! RESTORE SEGMENT ‘f ! 


POP 


Rl. 0R15 


LD 


R2,VPT.RUNNING_LIST(R13) 


LD 


R3.VPT.VP .DBR(R2) 


! UNLOCK VPT ! 


CLR 


VPT. LOCK 


! unmask VECTORED INTERRUPTS ! 


El 


VI 


MULT 


RR0,#4 


LD 


R0,R3(R1) 



RET 

END ITC GET SEG PTR 



02C6 9E08 
02C8 



02CS GST CPU NO PROCEDURE 

- SIND CURRENT CFU_NO - 

- CALLEI) BY UIST MMGR 
=p AND MM 

^ jp V »ie sp J? >P ’it s? s? V 5# 5? »? >? W SK V j:« V V >? sp 

- RETURNS - 

- Rl: CPU NO ==* 

- R 2 : # of VP'S - 



02C8 


6101 


ENTRY 

ID 


Rl, PRDS .IOG_CPU_ID 


02CA 

02CC 


0A0C ' 
6102 


LD 


R2, PRDS.VP_NR 


02CE 

02D0 


0A0S ' 
9E08 


RET 




02D2 


END 


GET_CPU. 


_N0 



02D2 


K_LOCK 


PROCEDURE 




f 5|t ^ nS ^3^ V ^ ^ V s;5S»s 


9,1 3^:9,: i;t 9^ 9,; 9,% 9^5 




'i' STUB FOR WAIT 


LOCK ’i' 



JiS S? 5? vpe sp Jr sp 5p sp >P 5? jp sp W 5? 5? Sp’p sp 5p >? W 



- R4:''LOCK (INPUT) - 

j;s^;^;p9^:^^;p^9;:’>t’PP<’Ptp’P’P’PPt’P’P’P’P’P’P f 





ENTRY 


02D2 


5F00 CALL 


0 2D4 


0282' 


02D6 


9E08 RET 


02D8 


END K_LOCK 


02D8 


K UNLOCK 



SPIN LOCK 



PROCEDURE 

I 9;cappc^^3^3p3^9;(3?:^^^v’PP::p’P’P’P’P’P’PPt’P 

STUB FOR wait UNLOCK - 

^ n«;i^ ;;c 9;^ ^ ^ ^ s;( s;c ^ ^ V ^ ’ic 

V R4:''LOCK (INPUT) 

^ m %• ««%« f 

#1% #>|p ««|% #|« «i|% #1% «|« #1* f 



ENTRY 

e2D8 0D48 CLR CoR4 

02DA 9E08 RET 

02DC END K UNLOCK 



END INNER TRAFFIC CONTROL 
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